home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
CD ROM Paradise Collection 4
/
CD ROM Paradise Collection 4 1995 Nov.iso
/
bbs
/
jdrbbs10.zip
/
DOCS_ETC.ZIP
/
DOCS.DOC
< prev
next >
Wrap
Text File
|
1994-12-22
|
432KB
|
7,891 lines
Juggernaut .10
Juggernaut is a complete Computer Bulletin Board System (BBS). It
has the power to do everything you expect from your BBS software,
and the flexibility to do its job in whatever manner you desire.
This software contains completely original programming, with many
new, and unique, ideas and methods. Including unlimited expansion
and growth potential. Incorporating much in itself that other
programs rely on 3rd-party software to accomplish.
The interface is FAST! Logging on and doing things are all
optimized in the interface. Hot-key menu action on all things.
The software is balanced. Users and sysops have many options, and
much power, at their control.
Raw POWER! Let the adventure begin...
CONTENTS WHY SETUP A BBS? ...........................................1
ORGANIZATION ...............................................2
LIMITS .....................................................3
NOTICE .....................................................4
REGISTRATION ...............................................5
Registered package .......................................6
DISCLAIMER .................................................8
SUPPORT ....................................................9
STARTING UP ...............................................10
TRY OUT ...................................................11
RESTARTING ................................................13
Config ..................................................14
INPUTING ..................................................16
Censoring ...............................................17
Active spelling checker .................................18
Search string chopper ...................................18
Internal Menus ..........................................19
CONSOLE KEYS ..............................................20
From <alt>d .............................................20
When a user is on-line ..................................20
Definable ...............................................21
Misc. ...................................................22
LOGGING ...................................................23
Callers log .............................................23
Errors log ..............................................24
Session log .............................................24
Chat log ................................................24
EH? .......................................................24
LOGIN .....................................................25
User Names ..............................................25
Login (cont.) ...........................................26
READING MESSAGES ..........................................27
Header ..................................................27
Body ....................................................27
Footer ..................................................28
Commands ................................................28
? .....................................................29
[Enter] ...............................................29
<right>/<tab> .........................................29
<down>/+ ..............................................29
<left>/<backspace> ....................................29
<up>/- ................................................29
Again .................................................29
Continue message ......................................29
Delete ................................................29
Edit ..................................................29
Forward ...............................................30
Get files .............................................30
Give files ............................................31
Next ..................................................31
Previous ..............................................31
Quit ..................................................31
Reply .................................................31
View a file attach ....................................31
eXit to menu ..........................................32
Sysop Commands ..........................................32
Misc. ...................................................33
ENTERING MESSAGES .........................................34
Heading Line ............................................34
In ......................................................34
To ......................................................34
Subject .................................................35
At ......................................................35
Line numbers ............................................36
Quote original ..........................................36
Upload message ..........................................36
Carbon Copies ...........................................37
File Attaches ...........................................37
Reception Report ........................................37
Encrypt .................................................38
Do A Freq ...............................................38
Net FAs .................................................38
Body ....................................................38
Command Line ............................................39
% .....................................................40
Abort .................................................40
Continue entering .....................................40
Delete lines ..........................................40
Edit ..................................................40
Finish later ..........................................40
Grammar check .........................................41
Insert lines ..........................................41
List ..................................................41
Preview ...............................................41
Save ..................................................42
MESSAGE FILES .............................................43
RAMBLINGS .................................................45
FILE AREA CONTENTS LISTING ................................46
Paged System ............................................46
The display ...........................................46
Command line ..........................................47
User commands .........................................48
Sysop/File-Op commands ................................50
Auto-delete curses ....................................52
Point & Shoot File Selection and Information System .....53
DOWNLOADING ...............................................55
UPLOADING .................................................58
Searching ...............................................59
File Descriptions .......................................59
REMOVING FILES ............................................61
MISC. .....................................................63
I AM LOST!?! ..............................................64
CUSTOMIZING 101 ...........................................65
TOGGLES ...................................................66
SETTINGS ..................................................67
PATHNAMES .................................................68
MENU COMMANDS .............................................69
ANSI'S ....................................................70
CONVERSION ................................................71
MODEM SETUP ...............................................72
Example .................................................73
CONNECTs DB .............................................74
Throughput ..............................................75
TERMINAL PROGRAM ..........................................76
Dialer ..................................................76
Command Line ............................................76
Misc. ...................................................77
CUSTOMIZING 201 ...........................................80
SECURITY LEVELS ...........................................83
Ghosting ................................................83
SYSOPS ....................................................85
Co-Sysop's ..............................................85
File-Op's ...............................................85
FILE AREAS ................................................87
Defining ................................................87
Menus ...................................................93
Diagrammed File Examples ................................95
Files In Area ...........................................97
CD-ROM's ................................................98
Special Cases ...........................................98
Ghosting files .........................................100
MESSAGE AREAS ............................................101
Defining ...............................................101
Menus ..................................................104
Toggling ...............................................104
PSEUDO-AI ................................................105
MINUTES ..................................................106
GROUPS ...................................................107
VOTING ...................................................108
DOORS ....................................................110
Defining ...............................................110
Menus ..................................................114
Time Maintenance .......................................114
Misc. ..................................................115
PROTOCOLS ................................................116
Defining ...............................................116
MENU SYSTEM ..............................................121
Definition .............................................121
McEditor ...............................................122
Menus ..................................................124
Command Objects ........................................126
Commands ...............................................128
Misc. ..................................................128
WAITING FOR CALLER SCREEN ................................130
THE "WHO'S ON" STATUS LINE ...............................133
ACCOUNT VALUE ............................................134
EVENTS ...................................................135
Defining ...............................................135
OH OH! ...................................................138
STYLES\LANGUAGES .........................................139
Directories ............................................140
Styles .................................................142
Languages ..............................................143
Your own style .........................................143
Menu Commands ..........................................143
TEXT FILE MANAGEMENT SYSTEM ..............................146
DIRECTRY'S ...............................................147
USER VOTING ..............................................149
Peer Review ............................................149
Sysop InfoForms ........................................150
DATABASER ................................................151
DB_BLKS.TXT DataBaser Structure ........................151
Calling Via Menus ......................................155
Modifying ..............................................155
More ...................................................155
LIFE & DEATH DELETE ......................................159
MULTI-NODE OPERATIONS ....................................160
INTERNAL NETS ............................................162
Null Link ..............................................162
LANs ...................................................162
Null LAN ...............................................163
FILE CORRUPTION ..........................................164
SPECIAL THANKS ...........................................165
NEXT .....................................................166
-1-
WHY SETUP A For the corporation, a BBS is an inexpensive method of
BBS? distributing software to its customers. Providing a way for
customers who do not have 3.5" disk drives to easily get the
software, rather than the company (and customer) going
through the time and expense of either sending a 5.25" disk,
or including both types with each software product. The BBS
optional provides faster turn-around response time as well.
A BBS also provides the corporation with a method of easily
distributing updated versions of each software product. When
a customer finds a bug in a piece of software, they blame two
companies: the original author, and the one that sold it to
them. Both companies have a good chance of never hearing
again from that customer. A BBS allows your older customers
to get the same software updates you include for the newer
customers.
Finally, it provides a way for the corporation to distribute
"undistributable" documents to its customers. Such things
as: complete price lists, technical specifications about
hardware products, "commonly asked questions" of your
technical support lines, documents on the historical and
tested performance of the various hardware products. The
same documents that companies sent to you to convince you to
carry their line can be used on a BBS to help generate sales.
For the individual, a BBS provides a temple of power for
yourself. Software comes to you. You provide a service for
other people. You are able to get your thoughts, ideas,
beliefs, and knowledge out into the world where all can see.
You can even make a BBS a business and get money running one
(if you are willing to make the initial investment to become
a huge multi-node BBS, or a smaller many multi-lined chat
BBS). A BBS provides you and your callers with access to
many mail echo's from around the world, and is a must if you
want to start your own mail echo to send around the world.
For the individual, who does not want to run a public access
system, a BBS program is superior to a normal communications
program because of its net mail capabilities. It also
provides a way to quickly exchange information between your
friends any time of the day as a private BBS.
Why this BBS program? Because it provides more flexibility
of design in its presentations to callers than any other BBS
program. What you envision, this software can make real; no
sacrifices, no compromises, only your vision.
-2-
ORGANIZATION Most of the user-accessible functions of a BBS need to be
relatively easy to understand when they are used on-line.
These docs were organized to provide additional information
for the sysop. In many cases, the details are of the type
that only a programmer would think to note--feel free to skim
past stuff you do not understand, and to skim even faster
past stuff you already do understand.
Typically, the first questions I am asked is "can the sysop
design their own menus," and "can the sysop move commands
from one menu to another"--Yes, to both.
Q&A.DOC contains some other questions I've been asked, and
might be worth looking over.
About half the docs are on-line in the form of on-line docs
for such things as Toggles, Settings, and Menu Commands. So
if you do not find the answer to a question in these docs, or
the HELP directory, try the on-line docs (most stored in
MENUCMDS.TXT if you want to print them out).
This software can be tricky. It does almost everything in
more than one way--leaving it up to the sysop to select which
way to do what they want. This capability adds some
complexity, but once you realize that it is "organized
complexity" you will be fine.
-3-
LIMITS Mostly your RAM and drive space are your only limiting
factors.
1000 file areas.
100 voting questions.
1000 message areas.
32,000 active messages per message area.
Message numbers can go to 2,100,000,000.
25 of your own defined data bases.
32,000 door programs.
99 undergoing-peer-review users.
32,000 entries in the databases.
32,000+ active users.
32,000+ active files on-line.
The above limits can be increased if needed, just ask.
-4-
NOTICE This is not a pre-release, alpha, or beta version. I will be
numbering my releases .01 to .99. "1" being a perfect
program, so anything short of perfection merely approaches 1.
"r.09" means "release .09", or "release #9". A release is
when I take the time to actually update everything and
distribute it to release sites. No small undertaking.
In between releases, I release JMODxxyy files which contain
any bug fixes, additional docs, and other interesting stuff.
XX will be the release number, and YY the release number for
the JMOD file. Example: JMOD0904 would be the 4th release of
the JMOD file for release .09 of JDR_BBS. Any releases
before the latest one are contained within, so there is no
need to ever get an old JMOD. JMOD files usually start
appearing about a month after release, and are updated about
every month or two.
I make a great effort each release to test everything for
bugs, but there is no such thing as bug-free software.
New versions will be released every 3 to 12 months. It is an
evolving product. In many cases, the ideas you relay to me
will appear in the very next release.
When I mention "sysop" that's you--and anyone of your same
Security Level (usually). When I mention "caller" or "user"
those are non-sysops. Example, when I say "users don't see
this" I mean that the caller will not see it, but at the
console you will see it.
If you find anything not to your liking, please tell me. New
ideas need not change the old method, this program is
designed to do many same things differently.
It is ready to run now, just INSTALL it and run it--even if
you are running a BBS on COM1, do not worry, it will be in
local mode.
-5-
REGISTRATION Required within 30 days of use.
See ORDER.FRM for pricing information.
The version you are using is fully functional. Registering
is required for continued use, and provides many additional
capabilities--including the source code (Basic/Assembly).
Many of these additional capabilities are listed on the sysop
menus in violet.
Besides the additional sysop commands, the post-upload-
processing stuff is also registered. That includes importing
FILE_ID.DIZ's, inserting archive comments, virus checkers,
etc. However, at the last minute I decided to allow
importing of FILE_ID.DIZ files (either after an upload or
with the Post Upload Processing sysop menu command) for ZIPs
only--to provide you a better opportunity to examine the file
system.
Thus, the unregistered cannot do the sysop commands in
violet, does very limited file post-upload-processing, and
cannot do compression-related stuff (compressing messages,
etc.)
What was selected to be registered were not things that
cripple the operations of the BBS, or penalize the users, but
rather enhancements that a sysop would like. Since,
ultimately, it is the sysop who registers this.
If you are a company, you must do a corporate registration.
If you are an individual, you may choose personal or
corporate registration.
Registrations are site licenses. Each computer running this
software must be individually registered. A single computer
multitasking three phone lines is considered one computer.
Workstations on a LAN or WAN are individual computers, but
usually only the server runs the software.
Cash, check, or money orders only. For extra safety, you can
send it via certified mail. A wire transfer may also be
acceptable, but require an additional charge. Credit cards
may be acceptable in the future, so if you want to use one,
ask first--but it is likely to add another 25% to the
registration fee (that was the fee of the last credit-cards-
for-BBSs provider I looked at).
Registrations are lifetime. Technical support is also
lifetime. All future versions will be considered registered
for you, with one exception: a possible Windows-only version
I may develop in parallel to this line. This software here
-6-
will be getting itself split into a DOS and Windows version
over the next year or two. The Windows-only BBS software I'm
thinking of doing would be a more simpler commercial version.
Registrations are non-transferable. You may not sell it,
trade it, or give it to someone else. One of the reasons for
the extra cost of the Corporate registration is that this
registration tends to transfer from employee to employee as
different employee's take on the task of maintaining the BBS.
This is acceptable for Corporate registrations as long as it
is inside the company. Personal registrations may not do
this. Example, a personal registrar may not give the
registration to his friend--personal registrations are
individual and non-transferable always.
Registration does not grant you ownership of the source code.
You may not recompile and resell the program in any form, or
parts thereof, without the authors permission. The source
code is solely for your own in-house modifications. If you
wish to license part(s) of the source code, contact the
author.
Registered Registration will get the registered version of Juggernaut.
package It is essentially the same program, but with a lot of extras
made accessible.
The registered package has, over these years, gotten reduced
to a single letter confirming that you are registered, and
card containing your key codes.
Everything else is given to you via File Attaches on
Immortality. In the future, I will be expanding this
capability to the distribution sites and Internet, and making
it much more automatic.
I have found that sending disks through the mail was just
getting them partially corrupt half the time. A mailman may
be willing to go through extreme conditions, but data on
disks hate it. Also, the software has simply changed too
fast to make printed manuals practical. Although I am
hopeful this will change in the future.
After registering, you will be given a package of files which
include a registered version of JDRBBS.EXE, the docs for the
registered capabilities, and information about how to hook
into the support network.
Other things include some free upload bytes on Immortality,
access to the encrypted Registered Sysops echo, your own node
address on the support network, and you can optionally have
your BBS appear in the list of active registered sites.
-7-
You will be able to get future releases free of charge off my
BBS. A distribution network is also being set up.
So register today! There are many good things yet to be
added to this software, and your support will help make this
possible.
-8-
DISCLAIMER I make no warranties of any kind, either expressed or
implied, as to the fitness of use, quality, or performance of
this software.
In no manner shall I be held liable or responsible for any
losses or damages arising from the use of this software.
See also: NOT_DOCS.DOC
-9-
SUPPORT I can be reached as follows:
Physical mail: John Rohner
POB 340304
Milw., WI 53215
If just a question, include a SASE.
Electronic mail: John Rohner (sysop)
Immortality
(414) 643-1576
Internet: rohner@csd.uwm.edu
Not stable, if no reply in a week then
call the BBS.
Usenet groups: alt.bbs
alt.bbs.allsysop
comp.bbs.misc
Also not stable.
Net mail: Immortality
(414) 643-1576
Must be direct call.
The BBS accepts mail 24 hours.
Voice: Rarely given out.
FidoNet: not yet...
I would prefer that you use a public area to post any
messages concerning this software. Usually the "Juggernaut
Support" area on my BBS. That way other sysops get to see
the message. Many private messages to me concerning
questions about the software will be forwarded to the public
areas.
Ideally, you should try to post the message in the following
order:
Juggernaut Support on my BBS (echo'd to other sysops).
BBS related echos on the Internet.
Feedback to me on my BBS.
E-mail to me on the Internet.
You can also contact any BBS which has registered the
software, usually they are pretty smart about how it works.
-10-
STARTING UP To make full use of this software, you will need the
following (listed in order of importance):
∙ A '286, 640k, or better computer.
∙ One or more hard disks.
∙ A modem.
∙ The latest version of PKZip/PKUnZip.
∙ A fossil communications driver (such as X00, BNU, etc.)
(included in the sample \UPLOADS area)
∙ A protocol driver, such as DSZ or GSZ.
∙ Your favorite text editor.
∙ An ANSI editor, such as The Draw.
The following are optional, but every good BBS needs them:
∙ The latest version of ARJ.
∙ The latest version of LHA.
∙ You will probably also want the latest version of PKLite
or similar (for reducing .EXE's).
∙ The latest version of BiModem.
∙ A disk defragmenting utility.
∙ A VGA monitor (for GIP graphics)
Don't be put off by that VGA monitor bit--it is in no way
required to use this software. But the software is getting
more graphical with each version, so it is nice to have.
If you cannot find any of the software on your local BBS's,
then give mine a call and you can download it from there.
The software works fine with disk compressing programs
(Stacker, DoubleSpace, SuperStor) and under a variety of
operating environments (DOS, DesqView, Windows). It does not
do any "oddball" things, nor does it attempt to take
advantage of the OS you put it in--it is environment
friendly.
-11-
TRY OUT Just run JDRBBS.EXE. It is configured with comm port = 0
(local/console mode) so you do not have to worry about
hooking up a modem/etc. right now. It will use the current
drive as its basis drive, and will initialize the #NEWUSER
new user record (the first user record).
#NEWUSER is the name given to the very first record in the
Users file. All new users are given a copy of this record as
their starting record. You may edit these values like any
other user entry, just specify "#NEWUSER" for the user's
name. For most things, the #NEWUSER entry/name is invisible.
Technical note: The software keys on the existence of
PATHS.DAT to determine when you first run it. It then
creates PATHS.DAT, BBS001.BAT, DOOR001.BAT, and BACKUP.BAT.
It also sets the comm port to zero, re-initialize's #NEWUSER
to the default settings, and sets the waiting-for-caller
drives-to-show to the current drive. Finally, it goes
through all your small SYSTEM\*.DAT files, and text-block
files, and changes "C:\" to whatever your current drive is,
and any "system operator's" to your sysop name. That is all.
Which means if you accidentally delete PATHS.DAT, you do not
have to fear for the rest of your files. Deleting PATHS.DAT
is a good first step when moving the BBS to a different drive
letter.
Because it is set for local-only operation (Comm port = 0),
it will automatically display the logo and start the login
process. Follow what it says. It is just like logging onto
a normal BBS.
One thing you will notice immediately is that instead of
"password:" I use "verification:". You can change it if you
like. "Password" was just too archaic for me. After all,
"my pass word", "]I[ %5^&890", and "643-1576" are all valid,
and hardly a word.
Now that you are in, play around with it, get to know it.
I have pre-created the following for you:
1 File Area: UPLOADS
a few Message Areas
2 doors: ED.EXE (PC-Write)
CSHOW.EXE (CompuShow)
7 voting questions
1 ramble
8 Security Levels
Some sample MESSAGE.### files.
3 Directry files: Unprotects
Music Quotes
Other Ansi's
A whole bunch of sample menu sets (Styles\Languages).
-12-
This is so you can get some general feel for the software and
its capabilities.
After looking around, hit <alt>u. This is the user
maintenance--change your Security Level to 100.
Hitting "!" at the main menu brings up the sysop menu.
You should make sure the .EXE and/or paths are correct in the
following instances:
File Areas Maintenance
Protocols
Executable Lines
Door Maintenance
Do not worry about the communication parameters for now.
You may quit the software by hitting <alt>x.
See also: CUSTOMIZING 101, CUSTOMIZING 201, MODEM SETUP,
CONFIG, SETTINGS, PATHNAMES
-13-
RESTARTING After the first time, always use "BBS001" (as in BBS001.BAT)
to run the BBS. Or rather BBS### where "###" is the node
number you wish to run. If using only one node, it is easier
to just copy BBS001.BAT to BBS.BAT and just type "BBS" to run
the program.
You may use JDRBBS /? (or BBS001 /?) to bring up a list of
what command-line commands are available. They are:
/? to get a help list.
/NODE=x to start up node x. Where "x" is a number
from 1 to 999. Optional for Node 1, but
required for any nodes larger than 1.
/PORT=x to re-set the current comm port to x.
Where "x" is a number from 0 to 4 (or
higher if your fossil supports it).
/BAUD=x to reset the baud rate the computer talks
to the modem at. "x" is one of: 1200, 2400,
9600, 19200, or 38400.
/INIT=x to define what your modem's initialization
string should be. Example: ATZ, ATE1X4,
AT&F&C1&D2H0, etc.
/1STCMD=xxxx to re-set the first command to xxxx.
"xxxx" must be a four letter command. You
may run a single command by doing:
JDRBBS /1STCMD=xxxx
BBS001 /1STCMD=STRT
the first part runs JDRBBS and executes the
command "xxxx", the second part re-sets it
properly. "xxxx" should not be a command
that requires the user's name unless you
put a "LogN" as the first command in
"xxxx"'s command list. Probably
"/BAUD=0" then "/BAUD=n" needs to be done
for some commands--otherwise it exits
because it does not find a carrier on the
currently defined port.
/NODIRECT to turn direct screen writing OFF.
/RESCAN do a complete re-scanning of your file
areas against what you have on disk,
updating your on-line file lists
appropriately.
-14-
/RESCANALL same as /RESCAN, but will do all areas
whereas /RESCAN will only do those areas
with File Area Attribute 9 OFF.
/USEVGA some sysop commands have VGA versions and
ANSI versions. When you use this, it
will select to use the VGA versions. It
will also change to 50 line mode when a
caller is using a > 25 video height.
**If you have a VGA monitor, and do not
need to run in text mode for something like
a multi-tasker, I strongly urge you to use
this parameter in your BBS001.BAT file.
It's great! Also lets you see what users
see if they have > 25 screen heights (which
otherwise mess up the local console).
/USE50 this will lock the console in 50 line
display mode. It also use the VGA
alternative displays.
/NOEVENTS this will not execute any events that were
to occur since the last time the BBS was
active. Useful if you had it off-line for
a while, and want to get on right away
rather than waiting for it to first finish
some scheduled event. It does not affect
future events, just those missed while
inactive.
Each command must have no spaces within it. So "/node = 1"
will not work.
"/", "-", "\", or nothing at all may be used as leading
characters.
There are Settings for the modem stuff, but these command
line versions are a bit easier, and provide a way to recover
if you enter bad modem information that doesn't set up the
modem properly.
Technical note: only those /cmds inside BBS###.BAT will be
re-executed if you do a full-exit door.
Config Below is what my CONFIG.SYS and AUTOEXEC.BAT look like:
CONFIG.SYS:
buffers = 25
files = 20
device = x00.sys T=2048 eliminate
-15-
AUTOEXEC.BAT:
path \dos;\bbs\bin;
break off
verify off
cd \bbs
Turning "break off" and "verify off" is an old BBS'ers trick,
allowing faster disk accesses.
If you just want to look around--not run the BBS, just ignore
the CONFIG/AUTOEXEC stuff.
-16-
INPUTING In most cases inputing of file names and user names utilize
"auto-completion"--you start it, the software finishes it.
With every keystroke, when entering a file or user name, the
software searches through all entries and looks to see if
there is only one possible match. The software will then
send the remaining keystrokes out--saving the user the need
to type it. If what the user types has no match, then it is
ignored.
I have found that, for user names at least, most sysops seem
to turn this off right away. But think twice before turning
off the file name auto-completion, it really is handy--helps
by not needing to memorize filenames.
When entering user names, you may type a "*" or a "?" anytime
after the first character. When this is detected, a list of
all the users matching those letters will appear. Example:
typing JOHN* would show all users with names with the first 4
letters "JOHN". This is mostly useful for when entering
messages TO: a person in a message area that allows any TO:
name (thus no auto-name-detect, such as net mail areas).
Some answer fields, that have a size limit, automatically do
a [Enter] when you reach the end of the field.
Security Levels, in some places, can be entered by entering a
range--either a single value, or two values separated by the
word "to" (eg. "5 to 20").
In most situations, a [Space] (or [Tab]) will pause the text,
and an [Enter] will cancel or exit an option.
For times, a 24 hour clock is assumed. This means that an
hour of "0" is midnight, "12 is noon. A day starts at
"00:00:00" (midnight) and goes through to "23:59:59" (11:59
pm). Because of the way seconds are stored, they may be off
by one second from what you entered. A 00:00:00 to 00:00:00
range means available 24 hours (indeed, any two matching
times mean to use the full 24 hours). For 24 hour
restriction, use 00:00:00 to 23:59:59. You must enter the
full 8 characters (HH:MM:SS) or you will get random results.
Phone numbers have become tricky these days. In order to
make everyone happen, no processing of what was entered is
done. Call-back verification is the only place this really
matters.
Whenever you enter full pathnames, you should always include
the leading drive letter. Example: "c:\uploads\test.zip" not
"\uploads\test.zip".
-17-
See the file HELP\KEYS.HLP on information about how to
colorize text and produce international characters (users and
sysops can do this--even in their names).
When a user receives a beep, such as during active grammar
check, or after file transfers, the console will not get the
beep (to preserve sysop sanity).
If you are the sysop, and/or at the console, then most of the
"inactivity time-out" timers will be ignored. This is not
true when doing some commands from the Waiting-For-Caller
(WFC) screen, as the software does not know who you are then.
Censoring This software has the ability to "censor" user inputed text.
This censoring is done only when entering file descriptions
or the body of messages.
There are three "levels" of censoring:
Simple case adjustment.
Removal of non-words.
Removal of superlatives.
All three are done when entering file descriptions, and only
the first two are done when entering messages.
Censoring is not done on imported or uploaded messages. It
is also not done when importing file descriptions.
You, the sysop, may toggle on/off this feature. You may
toggle removal of non-words on/off and you may toggle removal
of superlatives on/off. If both are toggled off, then case
adjustment is also off. If either one is toggled on, then
case adjustment is also on.
Simple case adjustment is the "correcting" of lower case to
upper case.
Examples:
" i " becomes " I "
"bbs" becomes "BBS"
".gif" becomes ".GIF".
Removal of non-words eliminates the word completely. The
words that are eliminated: "alot", "l8tr", "c00l", "k00l",
"gotta".
Removal of superlatives eliminates the word completely.
Words that are superlatives; excellent, great, super,
incredible, etc. are removed.
-18-
All three are done as the user enters the text. Case
adjustment is the only one that is not "demonstrated" at the
time. By demonstrated, I mean that when a user enters a non-
word in either a message or description, or a superlative in
a description, then they will see the word deleted before
their eyes--no matter how many times they repeatedly enter
it.
Of the above, the "alot" elimination seems to have caused the
most trouble--those who use this non-word seem to have
trouble stopping themselves.
Why censor superlatives? If you are an experienced sysop,
you know. Users will always try to add a superlative in
their descriptions, they seem to feel the need to "sell" the
sysop on the upload, this is particularly true of systems
where the upload must first be validated by the sysop before
others can download it. One can get tired of these non-
descriptions quickly. This is one of my favorite features of
this software (the other being automatic logging of removed
files).
Description censoring is not done when the user is the sysop.
You may add or alter the various censored words. See the
SHORT.TXT file for information on which lines contain the
censoring words.
Active Active spell checking is a form of censoring. While entering
spelling messages, it beeps whenever a word you just typed is not
checker found in the word lists. It beeps at the same misspelled
words that Grammar Check would highlight.
If both removal of non-words censoring and removal of
superlatives censoring are turned off, active spell checking
will not operate. If you do not want censoring, but want
active spell checking, then leave one of the censors toggled
ON, and clear out the SHORT.TXT entries for it (so it finds
nothing to censor).
Active spell checking can be turned on and off by the user,
but it still requires that you have censoring ON to work.
Search Another form of "sort-of" censoring is the search string
string chopper. This occurs after a user enters a search string to
chopper search the "off-line" lists--either from the search lists
command, or from the search-lists-before-uploading command.
Our first attempt to censor begins by presenting the user
with a 10 character field for them to enter their search
string. The purpose of this limitation is to remind them
that they are searching for text, not filenames. After all,
-19-
filenames do not really mean anything--they can change from
one BBS to another. I like to think that when they type
FILENAME.Z and find that they cannot do the "IP" that their
brains realize that maybe the filename is not such a good
search.
Then we do some visible editing of what they typed.
First we chop off anything after a "."--any extension.
Then we clear out any non-alphabetic text--like numbers and
stuff. Things that really only appear in file names. The
sysop has a toggle to control whether the software should do
this or not. For instance, however, "X00" would become just
"X" and not searched for--but "XX_1094.ZIP" would become just
"XX" and not searched for either. It is a bit of a trade-
off, which is why I left the ultimate decision in a sysop
Toggle.
Then we check what's left against our list of non-searchable-
entries (see SHORT.TXT). Such as ZIP, or GIF--things for
which there are just too many entries, and for which a smart
user could get a master list of all files on the BBS
regardless of their security level.
Finally if what's left is less than three characters we just
drop it--far too many one and two character entries to be
displaying.
The system works. Users that continually enter filenames
will usually see them chopped down to nothing. Even those
that get through will usually produce a warning: "searching
for a filename is not recommended."
Internal Menus At various times, for various situations, the software will
use it's own internally generated menu to offer you, or your
users, selections.
The colors for this internally generated menus can be defined
by you with Settings.
These menus attempt to put all the options onto a single
screen. To do that, sometimes some get squeezed down a bit.
But at some point, they get squeezed down so much they get
unreadable. Example: with 200 options, they display only
about 5 characters for each.
To get around this, the software has a threshold Setting.
When the squeezing falls below this number (10 being a good
number) we use a vertical selection window instead.
-20-
CONSOLE KEYS I don't go into them here. They are fairly simple to
understand, and once you use them you'll usually remember
them.
These are just the keys that: lead to more information, are
most used, or need some extended explaining.
From <alt>d <f10> is the key to remember, it provides help on what
the other keys are while you are connected.
When a user <f10> is the key to remember, it provides help on what
is on-line the other keys are.
<alt>h hang up on the user.
<alt>c to chat with the user.
Hit <alt>c again to exit chat.
Hit <f10> for the chat keys' help.
You can also just type "cls<ret>" to clear the
screen when in normal chat (vs. 2-way chat).
To safeguard the integrity of other routines, this
only works from the menu's.
<alt>k to delete the current caller when they log out.
I like to use this as a quicky way to get rid of
callers whom I know I will be getting rid of later
(like those who call using handles like "Dan").
<alt>u to do user maintenance.
"User" menu command. The caller does NOT see
anything, and any keys the caller types are
executed after you exit the user editor. You can
make changes to the current caller, or any caller,
and those changes will be immediate.
To safeguard the integrity of other routines, this
only works from the menu's.
<alt>x to do an immediate exit to DOS.
This does not save anything. It only works when
you are logged on at the console. Does not take
the phone off the hook. You can use this command
anywhere--but because it does not update the
active users record (which is usually you) it is
best to use it from WFC.
<alt>s to shell to DOS.
Does take the phone off the hook.
<alt>z This is a cross between <alt>x and <alt>s--it
exits the BBS quickly from anywhere without saving
anything, and takes the phone off-hook. See
<alt>x above.
<f8> Accesses NOTEPAD.TXT--letting you send any lines
from this file as if you typed them at the
console.
<f5> toggles the screen (a screen clearing is done)
between 25 and 50 line modes. VGA is required for
this.
<alt>p Pure mode. Direct access to the modem command
-21-
mode. This is mainly useful with sysops who call
using <alt>d. If you wish to show them something,
or explain problem, then you hit <alt>p on your
end, and they hit <alt>L on their and, and you
will immediately be able to log in on their BBS
(rather than you calling, it's their "dime").
Increasing the callers SL allows you to do sysop things from
the console while another user is on-line, such as allowing
you do demonstrate the sysop capabilities to another user.
When you are in a DOS shell (such as using <alt>s--which can
be used from Chat as well), two useful commands are: "DSZ rz"
and "DSZ sz filename.ext". The first receives files the
person at the other end is sending, and the second sends
"filename.ext". Both assume comm port 1, and you may need to
change to the directory with DSZ first.
See also: THE "WHO'S ON" STATUS LINE
Definable You may define <ctrl>F1 to <ctrl>F10. See SHORT.TXT.
These lines can contain the menu commands you wish to be
executed when you hit <ctrl>Fx keys. You aren't restricted
to 4 letters.
These control sequences will be allowed from anywhere, so be
careful.
This is an extremely powerful, dangerous, and unpredictable
ability of the software. It relies on you to know when a
menu command should or should not be executed--especially so
when a user is on-line.
They are probably best used to call a door from the waiting-
for-caller screen (hint hint).
Because you may enter any menu command, and do the command at
any time, you can see how problems can arise. Particularly
important to not do: user commands when no user is there for
the software to find or update (such as at the Waiting-For-
Caller screen).
Only trial-and-error will let you know when to use that key
to do what you want, and when not to (ie, the system
crashes).
I have predefined <control>F2 as the "MCED" command
(McEditor). Very useful when you design yourself into a hole
in your menus.
-22-
I have predefined <control>F3 as the "MHlp" command (Menu
Command Helper). This is the "H" from within McEditor and
provides you with full screen access to information about the
various menu commands. Useful for browsing and re-confirming
the functionality of a command.
Some commands probably will not work if the current comm port
is not zero (because the software does not detect a carrier
signal on the current port). You can get around these by
using "PORT". For example: "PORT _0 ABCD PORT_1" which first
changes to comm port 0, executes command "ABCD", then changes
back to comm port 1.
See also: MENU COMMANDS
Misc. The way the program works is like a hub and spoke system
(such as a large city in relation to the smaller cities
around it).
Menus represent the central hub. From these you go to many
sub commands.
This means that most commands are sub commands and not part
of the main hub.
So, for safety's sake, you should only execute console keys
(such as chat, or <ctrl>Fx's) from the menus when a caller is
on-line.
The concept is that you can go to the sub commands from the
main hub, but you should not jump from sub command to sub
command directly.
For you programmers: even though Basic has re-entrant
capabilities, exploiting them by jumping from sub to sub
without going through the central hub (Dispatcher) could
conflict with the global variables and distort them. Thus
leading to unpredictable and potentially disastrous results.
However, Basic is very robust, and usually you will have to
be pretty unlucky for anything bad to happen.
The "dinky" stuff, such as <alt>h or beeping, you should not
worry about. It is the chatting, shelling to DOS, running a
door, etc. that are likely to cause troubles for you if you
execute these "inside" a sub module.
-23-
LOGGING Both the Callers log and the Errors log can be limited in
what they show using Logging Toggles.
These logs are all standard text files. Feel free to simply
delete them whenever you feel like it.
See also: TOGGLES
Callers log This has the file name CALLERS.LOG.
The callers log contains 3 types of data lines: user, file,
and system.
The system lines all start with a "|=", and contain
informational messages from the BBS to the sysop. Users
cannot see these lines.
The user lines begin with the date and a user's name. For
all users to see, it is mostly who logged on when.
The file lines come straight out of the protocol log files.
They do have any paths stripped out first. You can toggle
these on/off in the File Area Definitions.
When listing the log, users are shown the user lines and the
file lines. When the sysop lists the log, he is shown all
lines.
From the information shown, users can deduce the following:
∙ Who called, when, and from where.
∙ Who upload files--in case they would like to contact the
uploader with a question.
∙ Who downloaded files--to see if a friend downloaded a
file (saving them the trouble) or to see what kind of
download interest their own uploads have gotten.
∙ Who lost credit for duplicate/bad uploads.
∙ Who passed, or failed, Peer Review.
It is also useful for other sysops, they can see who are good
users and who are bad users. Perhaps leading to increased
access for these good users on their own board.
Technical note: when you list the log using an external list
utility, note that the user who did the actions comes after
what they did. That is, when using something like LIST, the
user that did a file transfer is listed after those file
transfer entries. The file should be read bottom-up. When
using one of the software's internal log lister's, this is
taken into account and is listed correctly with the person's
name first and their actions on the following lines.
-24-
Errors log This has the file name ERRORS.LOG.
This log contains important error messages, or unimportant
minor adjustment notices.
** IMPORTANT **
When you have a problem, you should check here first to see
if it might have helpful information.
** IMPORTANT **
Session log This has the file name SESSION.LOG.
The session log is an I/O trap log, and will contain the I/O
exactly as it was sent and/or received--including all the
ANSI codes.
There are useful sysop commands to slow-view these ANSI files
and to strip the ANSI codes out of the file.
Chat log This has the file name CHAT.LOG.
The chat log contains the trapped chat sessions.
EH? Are you still reading this without trying the program? Now
would be a good time to try it out, otherwise the detalia in
the following sections will become confusing.
-25-
LOGIN The login sequence begins from the time of connect (when we
usually display a logo or somesuch) until we display the main
menu. This is referred to as the "Login Loop of commands".
At any point during the login sequence, the sysop may define
that one or more ANSIs be displayed. The sysop may also add
or delete various other capabilities (such as news) that can
appear during the login process.
User Names You can use just about anything for the login name.
Examples: "|017th |15Guest", "Jo├┤N rOhNΣr ]I["
But it does make its own intelligent changes:
"john rohner" -> "John Rohner"
"JOHN MCADAMS" -> "John McAdams"
"john Doe" stays the same.
When logging in, a caller may start their name with "=".
Example, "=John Rohner". What "=" does is disable auto-name-
detection. This is useful for users that use scripts, since
with auto-name-detection their "key sequence" that makes up
their name, may change from login to login if a similarly-
named user is added, or deleted, from the user list.
Auto-name-detection at logon always gives me a good chuckle.
This occurs when a new user calls the second time, and types
their name, with the software producing half of it. They
just pause, and you feel the disbelief they are undergoing,
"How the heck did the BBS know that...".
If the caller just hits [Enter] for their name, then auto-
name-detect is immediately turned off (without bothering to
tell the caller).
If the caller just hits [Enter] for their password, and it is
not their password (yes, passwords can be nothing) then the
software will turn off auto-name-detection.
Users now REALLY have two names: a normal name, and a Real
name. The normal, usually the alias, is what's seen.
However, the Real name is now so real, that the user may
logon using either (normal name will be displayed).
When listing the users, both normal and real name will be
shown as users. It was necessary to do this, as the ability
to change names, IEMSI, and other real name stuff (like
stopping duplicate names) requires that I mix real and
alias/normal names in the index.
-26-
For this reason, "List Users" will show both names (real and
normal). So if you require real names, but yet your users
are paranoid about others finding out the real names, you
could either put the real names into Sysop Notes, or disable
the "List Users" command.
Also because of this name duplicity, it will also wrongly
show the number of active users in the stats.
Login (cont.) If the user has defined a logon note, it will be shown during
the login process.
If the caller has any unread mail waiting for them, they will
be given the option to read it at login.
If the caller has multiple messages waiting, they may select
to Scan the messages (hitting "s") which gives a single line
of information about each message waiting for them.
Multi-node limitation: the login system stops the same name
from logging on multiple nodes. The exception to this is the
sysop. The reasons for this exception: because <alt>x still
leaves your name as "logged in" on that node which makes it
tricky to log back in. The second is that it's assumed
(perhaps wrongly) that the sysop knows what the heck he's
doing. We stop users because their records would get all
tangled up--but I should be fixing this in the future.
Technical note: if you do something to a user on node 1,
while you are on node 2 (such as give higher SL, or send a
message to), it will not occur. I would call this a bug, but
it occurs because that user's record on node 1 is stored in
memory, so if we change the record on disk, it does not check
for changes before re-writing the user's record back out when
they logout. When I fix this, then I think allowing the same
user on multiple nodes will be possible.
New users will be asked for their screen size using a rather
odd method: we output 50 lines with numbers and ask them
which they see at the top. We do this because "viewport"
size is crutial with this software--it tries to use the whole
screen. We do not want to be confusing the user by asking
for a screen size--to which he might enter 25 when all he can
see is 22 lines.
See also: MENU SYSTEM, LogN, Welc, STRT
-27-
READING When you select a reading messages command from a menu you
MESSAGES will be given the range of message numbers and the number of
new messages. You will be asked to enter a message number to
start at, or type "N" to start at the first new message. The
exception to this is when logging in and when reading Private
Mail (if you are not a Message-Op), then it just displays the
first appropriate message to the command (such as first new,
or first to/from the sender, etc.).
A message is then displayed.
We use a nice screen-sized window reader. The commands are
just what people expect: [enter] for next page, "R" to reply,
"Q" to quit, [enter] for next message, etc. But there are a
lot of commands available, hit "?" to bring up a listing of
the available commands.
Header The message's header information contains the following:
Current Message Area.
Current message's number.
The last message number in this area.
Who the message was from (and maybe their net address).
Who the message was/is to (and maybe their net address).
The date/time the message was sent.
The date/time the message was received.
The subject of the message.
If the message is a reply to another message.
If the to/from name is an active/current user (toggle).
If Net Mail messages have been [sent].
The sysop has a couple toggles to control what is seen. These
are set in the Message Area Definitions.
If the Message Area is a Net Mail area, and the net address
is not zero or your's, then the net address will be
displayed.
Messages have a counter that is updated each time the message
has been read. When the Message-Op of the area reads the
message, however, the counter is not increased. This allows
you to, say, review Private Mail without a user wondering why
his private message says "read 2 times".
Body The body area of the message is displayed using user-
definable colors.
A Message Area Attribute may be set to show "hidden" net
information for Net Mail messages as well. The information
then shown is:
Hidden "Kludge" lines. Such as PID and MSGID.
EchoMail "origin", "tear", and SEEN-BY lines.
-28-
You can move up/down through the message (either one line at
a time or by pages) using the arrow keys. [Enter] will go to
the next page, until you are at the end of the message, then
it will go to the next message.
If the software determines that the message is an ANSI, it
will display it all at once. This can really mess up the
screen if the ANSI doesn't start with a clear screen command.
Choosing a black background when reading these messages can
help a lot.
Footer After the body, is a single (dark) line of information that
shows:
Total number of replies to this message (toggle).
Date message was last read by anyone (toggle).
Total number of times the message has been read (toggle).
The user has a couple toggles to control what is seen.
This line does not appear until the end of the message has
been reached. So this is a convienent method for you to know
when you have reached the end of the message.
Commands The main command is "?", which brings up a help screen.
When reading a message from a Scan Messages command (or
something else like the Zombie Messages), almost all the
commands will not work. I'll fix this in the future.
A number may be entered. This is a "jump to number" order.
The message in the current message area that corresponds to
that number will then be displayed. Deleted messages are
ignored. If no message has that number, then the first
message with a higher number is displayed.
Auto-detect for ZModem and BiModem uploads is also done. If
you were the poster of the message, the files will be
attached (useful if you forgot to do the File Attach
command). If you are not the poster, then we exit to a menu,
and the uploads will be stored in the upload area 001 (that
is, it will work just as if the person did an auto-detect
upload at a menu).
After some of the below commands, we move to the "next"
message. If the user had been doing "Next" we go to the next
message number higher, if they had been doing "Previous" we
go to the next message number lower.
-29-
? Brings up an ANSI listing of the commands available.
For the sysop and co-sysop, a second ANSI listing also
appears.
The help ANSIs are stored in HELPBLKS.TXT--feel free to
change them.
[Enter] Display the next page. If at the last page, go to the next
message.
<right>/<tab> Display the next page of the message.
<down>/+ Display the next line of the message.
<left>/ Display the previous page of the message.
<backspace>
<up>/- Display the previous line of the message.
Again Read the same message again.
Continue This command will allow (only) the author of the message to
message continue the message as if they had never stopped. It jumps
them right back into the entering message text system.
For this to work, the author must have saved the message with
"Finish Later".
See also: ENTERING MESSAGES
Delete Delete the current message.
Only the sender, receiver, or Message-Op may do this.
If the message contains file attaches, the software will ask
for a confirmation.
The user also has a toggle to confirm the deletion of each
message.
Edit You may edit/alter an already sent message. It is simple
search and replace. You give it a string to search for, and
a replacement string, and it does it.
For historical accuracy, the replaced text is never "really"
replaced. Editing gives you an opportunity to clean up a
message. But it also offers an opportunity to "rewrite" what
you said. To stop any kind of abuse: the original text has a
backspace character added after each character--too fast to
notice when reading, but noticeable in backscroll/capture
buffers.
-30-
Example, I have the message "Howdy, thar!", and decide to
edit out "thar" and replace it with "there". When reading,
it is seen as "Howdy, there!", but in the backscroll buffer
you might see it as "Howdy, t▓h▓a▓r▓there!" depending on what
type of communication program you are using. Historical
accuracy is maintained, while giving the ability to alter
already-sent messages.
Only the sender, receiver, or message-op may edit it.
Forward You may forward the message being read to another Message
Area or another user.
A note, "Forwarded from" is added to the top of the message.
A sub-note may attached to the top or bottom of the message.
This is useful for explaining why the message was forwarded,
or to add a comment before sending it onto the next person or
Message Area.
Only the sender, receiver, or Message-Op may forward a
message. The current Message Area must not have the don't-
delete Attribute set.
Technical note: Message Area Attributes, such as always-use-
ANONYMOUS or always-use-ALL, are ignored. If the message has
normal TO/FROM fields, then if moved to a Message Area with
those special Attributes, it will still contain the normal
TO/FROM fields, rather then be given the "FROM: Anonymous" or
"TO: ALL" to which that area normally demands.
Get files This option is used to download files that are attached to
the message.
If you are the author of the message, it goes to "Give Files"
instead of this.
The files successfully downloaded are subtracted from the
user's can-download bytes and daily time stats--unless they
are "(Free)".
If there is only one file attached, it will begin sending it.
For more than one attach, it will ask you to select which
ones you want.
The files are subtracted from the user's can-download bytes
and daily time stats. This is done for all the files
attached to the message, and regardless of whether one or
more of the files were successful or not. That may sound
strict, but it helps discourage use of the file attach system
as an upload system (for interpersonal uploads).
-31-
Give files This option is used to attach files to a message.
If you are not the author of the message, it will instead do
a "Get Files" command.
The author can use this command to continue or add to the
uploads related to a particular message. This command is
mainly useful for finishing <incomplete> file attaches.
A "Continue Message" for file attaches.
No upload crediting is done on file attaches.
The author need not have specified "Files Attached" when
originally writing the message for this to work.
Next Read the next message in the message area, or move onto the
next message area if reading mail at login or using the "Read
All New Mail" command.
Previous Read the previous message in the current message area.
If reading mail at login, or using the "Read All New Mail"
command, and there are no previous messages, it does not go
to the previous area, but exits the reading of messages.
Quit This will quit reading the messages.
If you are using "Read All New Mail" it will quit the current
Message Area, and go to the next area.
Reply Enter a message in reply, to the sender of the current
message.
View a file This command will display a file attach. Nothing fancy is
attach done, it simply sends the contents of the file.
This is extremely useful sometimes. It allows a user to post
a message greater than your line limit (or 16k). You could
maintain a small library of text files in a message.
Disadvantages with this are that you cannot quote from the
file, and it relies on the formatting of the file rather than
then internal word wrapping/etc. formatting stuff.
If there is only one file attached, it will begin showing it.
For more than one attach, it will ask you which one to
display.
The software will automatically not view the file if it is an
archive.
-32-
eXit to menu This is the same as "Quit", except when doing a "Read All New
Mail" it quits that too.
Sysop Commands Where is says "or Message-Op" above, it means it--even the
sysop is excluded. But, of course, it is the sysop who
changes who the Message-Op is. Anyways, Sysop's and Co-
Sysop's have their own commands. Neither users nor Message-
Op's can do these.
U User Maintenance
Access User Maintenance to edit users.
S Show Hidden Info Toggle
Show hidden Net Mail information.
& Msg --> File
Store a copy of the message to a disk file.
! Msg --> New Msg Area
Move this message to anther area.
@ Edit Msg Info
Edit this messages' header.
> Move All File Attaches
Move the file attaches to another directory.
# Kill All File Attaches
Delete the File Attaches.
^ Re-Inform User
Re-inform the receiver about this message.
* User & Msg --> Peer Review
Send the user to Peer Review processing.
/ AI's "Go Fish" Reply
Give a standard sysop reply ("look around for yourself").
<alt>1 PGP Decrypt: View
Decrypt the message using the Sysop's key, then view it.
<alt>2 PGP Decrypt: Re-Save
Permanently decrypt the message using the Sysop's key.
Of the commands above, a Co-Sysop cannot do the following:
Msg --> File
Move All File Attaches
Decrypt Messages
The software's "AI's Go Fish" sends the user a quoted reply
of their message, and adds a note that they should look for
-33-
the information themselves. The message is sent from the AI.
The original message is deleted. The text of the reply is
stored in TXT_BLKS.TXT block number 13. You may edit it to
your liking.
The Peer Review processing is part of the Peer Review voting-
on-a-user system (explained later). This command will send
the message to a special message file, delete the message,
and then send a prepared AI reply message to the user. The
user "undergoing Peer Review" Attribute "0" is also turned
ON. The special message file is a Peer Review MESSAGE.P##
file, from which users participating in Peer Review will get
the information to make their voting decisions. If you
execute this command when the user already has a Peer Review
file, then this message is appended to that file--to provide
further information for reviewers.
The "re-inform" command will "re-flag" the user of the TO:
field telling them they have a message. This command is
useful after you have accidentally deleted your USERMSGS
file--since rebuilding it sets all pointers/etc. to zero--
this should be used on all "(Rcvd: -NO-)" messages. It is
mainly only used for when something goes wrong. But you can
pester the user by re-sending a message they may have ignored
also.
Misc. If the sender of the message had included File Attaches, and
you respond with "Peer Review" or "AI's Go Fish", than these
File Attaches are deleted as the original message is deleted
automatically.
When you move a message (either with the sysop Msg-->New Area
command or the Forward command) the message will be given the
next message number appropriate to that (destination) area.
If a message has File Attaches, they are kept intact and with
the message when you move it around or re-edit it, or even
Continue Later it.
-34-
ENTERING Leaving messages is a two step process. The first step asks
MESSAGES you about the message attributes: subject, whether to quote,
etc. The second step handles the entering of the message
text and the various entering messages commands, most
notably: saving.
During this first step, entering of information, you select
the first letter of what you want to do/change, and then
[Enter] alone to move on to entering the message's text body.
All of the various "objects" on the screen are active
commands. Hit the first letter of the object name (eg. "T"
for "To") to alter that objects data or state. However, some
of these options may not work--either because of the type of
message, type of Message Area, or with each other--then you
will get an informational note saying it cannot be done.
Heading Line The first thing displayed is a heading line. This line
contains information about the type of mail to be sent:
Public, Private, Anonymous, and Net.
Because there are only two types of "From:", the posters name
or Anonymous, there is no "From:" field shown.
Attributes in Message Area Maintenance define what type of an
area it is to be. So if when posting a message you see that
this heading information is wrong, you should recheck your
Attributes for that area.
In This is the name of the message area to which the message is
being posted.
This command option can be used to move the message to a
different Message Area. Only those areas which the user both
has toggled ON, and access to, are offered.
To To whom you wish the message to go. For replies, this is
given the name of the poster of the original message.
If the message area allows it, "ALL" can be used.
If the message area is an EchoMail or NetMail area, then any
name be entered, otherwise the name entered must be that of
an active user.
Entering "Sysop" will expand out to the message-op of that
area. Entering "Fellow" will change to "All", which then
changes to "Fellow Sentient Beings" (you can change this, see
Settings).
-35-
You may use "*" or "?". This will bring up a list of the
first 20 names matching the characters you have entered so
far.
Subject The subject of the message. For replies, this is forced to
be the same as that of the original message.
The subject field of a message is a variable thing--it
depends on the type of text you type. This is because the
message subject's text is compressed.
If you type a long subject, and the system "deletes"
characters at the end of it after you hit [Enter], then you
know some of subject has just been deleted because it turned
out to be too long. Usually only occurs with subjects that
are all uppercase characters.
Any leading spaces are trimmed off.
At This is the NetMail address to send the message to (if the
area is a NetMail area).
Hit a "?" to get some help on what to enter.
Merely hitting return will set it to zero--making it a local-
only message.
The net address supports the Fido format, which is
xxxxx:yyyyy/zzzzz. Where "xxxxx" is the zone number, "yyyyy"
is the net number, and "zzzzz" is the node number. But you
can type "x.y.z" or "x y z" or most anything and it will
work.
The software uses your net address to fill in any missing
information. That is, if your address is "a:bbb/cccc", then
entering only "##" will be converted to "a:bbb/##", and
entering "##/##" will be converted to "a:##/##".
A private message without a net address in a Private NetMail
area will be, instead, correctly put into Private Mail area
(001) instead.
You are able to send messages to net addresses not in the
sysop's nodelists, but there is no guarentee these messages
will reach their destination.
Besides Fido-style addresses, you can enter Internet style
addresses (name@domain.site, but actually anything). The
software will properly store these addresses with the
message, but at this time does not use them for anything.
There is a Message Area Attribute to turn this on.
-36-
Line numbers This toggles ON/OFF whether you wish to see line numbers at
the start of each line when entering the message text.
It is very tricky to edit a message without line numbers.
But turning line numbers OFF allows one to put more text into
a message, and makes large ASCII sends (from caller) of text
more reliable.
Quote original This will quote the entire original message when doing
replies.
When entering the body of the message, you may then use
Delete to remove any quote lines you do not want, and Insert
to insert between quote lines if you want.
You cannot upload a prepared message and quote the original
at the same time.
Upload message Upload a prepared message.
You will not be allowed to select this option if you already
have selected to quote the original message.
The uploaded file should be a standard text file. Not
compressed, nor any other weird characters (those below ASCII
32). ANSI codes and graphics characters are allowed, but it
would be better for everyone if they were File Attached.
When this feature is used from the console, it is called
importing. You will then be asked for a pathname to load in
as the message. The original file will not be deleted.
Processing includes truncating any additional lines beyond
your set maximum number of lines allowed in messages.
Normally that is 98 lines.
This command can be used to import/upload text files and .REP
packets. However, if the console does import a .REP it will
be deleted after importing.
Uploading/importing an ANSI for a message (or part of a
message) is easy. Just remember: no ANSI line longer than 78
characters--word wrap does screw up long ANSI lines. File
Attaching is usually a better solution because it lets one
attach very large ANSIs and allows the user to download the
ANSIs intact if they want.
When uploading an ANSI, only the maximum number of allowed
lines per message are imported from the file (usually 100 or
200). After uploading, the screen will look horrendous, just
ignore it and do Save right away.
See also: SETTINGS, MsgD
-37-
Carbon Copies You may send multiple copies of private messages to many
users. These are known as CC's.
When you save the message, the software will ask you whether
you wish to include all these names at the top of each
message, or not.
You are not able to send CC's in NetMail, EchoMail, or with
File Attaches.
File Attaches Select this if you wish to attach files to the message.
When the message is saved, the software will ask that the
author upload the files to be attached. Or, if at the
console, the pathnames you wish to duplicate and attach to
the message.
Files Attaches are stored in the MSGSTUFF directory. Each
message with files attached will have its own directory under
the format: MessageNumber.Area Example: Private Mail (area
001) message number 5000 would be stored in \MSGSTUFF\5000.1.
You, the sysop, may add or delete the files and/or directory,
without concern--there is no internal tracking done for the
File Attaches (the directory is either there and contains
files, or it is not).
If you forget to select File Attaches, or just want to be
lazy, then you can "just upload them" at the command line.
This will cause the message to be saved, and for it to begin
receiving the transferred files and attach them to the
message. This does not work from the console.
If the upload is aborted, or you want to add more later, you
can do so when reading the message.
You cannot do File Attaches with Carbon Copies.
Only the sysop can make the File Attaches free.
Reception This will drop you a short message confirming that the person
Report received and read this message.
This can only be used with private messages.
The RR is sent when the user reads the message on-line
(usually at login), but not if (for some reason) they
download it (like in a .QWK packet).
-38-
Encrypt This is a sysop-only command that will let you encrypt the
message with PGP.
For this to work, you must already have the public key of the
person to whom the message is TO: on your PGP key ring.
See also: PGP.HLP
Do A Freq This command allows the sysop to do FREQ's (File Requests)
from other BBS's via Net Mail.
The actual FREQ attempt will be done when the sysop calls
manually with <alt>d and hits <end>, or the next time the BBS
calls that BBS number for a normal net mail exchange.
You may do a "crash" (immediate) version of this command from
the waiting-for-caller menu.
See also: NET_MAIL.DOC
Net FAs This command allows the sysop to Net Mail files without
needing to make them File Attaches as part of a message.
Like "Do A Freq", the actual mailing of the file is done the
next time your BBS calls their BBS and exchanges mail.
You may do a "crash" (immediate) version of this command from
the waiting-for-caller menu.
See also: NET_MAIL.DOC
Body Entering of text is straight forward.
Quoted text shows up bracketed.
Hitting backspace can go to the previous line.
Cursor movement keys (up, down, left, right) are converted to
backspaces (up, left) or spaces (right, down). There is no
moving about the message with the cursor keys (yet).
With the exception of the cursor movement codes, ANSI codes
are allowed in messages.
Technical note: These cursor movement keys are "[A", "[B",
"[C", and "[D". Now, these codes are a subset of the full
ANSI set--so if a user wanted to upload a complex ANSI,
theses codes might be part of it and screw it up. But the
vast majority of times these keys get encountered are when
the user tries to move around the screen to do editing. To
use the same codes in an ANSI image as part of the message,
one should use: "[1A", "[1B", "[1C", and "[1D".
-39-
There is trouble, however, with ANSI lines that exceed 78
characters. So, while ANSIs are best in single-line form for
menus, for messages they need to be in multi-line form.
TheDraw can handle both forms. To put ANSI codes into
messages remotely, you must either do an ASCII file send of
an ANSI file, or upload that part of the message as a message
upload (then the cursor movement keys are allowed in the
ANSI).
ANSIs jumping all over the screen using either positional or
cursor movements keys is simply not the way to do in-message
ANSIs. The proper way is to design your ANSI to display a
line of ANSI text/drawing, do a CR/LF, then display the next
line of ANSI text/drawing, etc. until done. Like sending
ASCII text, but with hidden ANSI codes.
Quoting of text with ANSI characters can mess up the quote
brackets' appearance--unless one follows the guidelines
above.
Graphics characters (ASCII codes above 127) are also allowed
in messages.
Exit to the command line by hitting enter twice.
One may also type: /s, /es, /post, or /exit at the start of a
line to immediately save and exit the entering message
process. All the commands work alike.
Hanging up saves the message (as "Finish Later"), but loses
the line being worked on.
If a user has toggled active grammar checking to ON, then
each word is checked as they enter it, and a beep is sounded
when that word is not found. User's should not have this
option ON when doing an ASCII send of message text from their
communication program's buffer or from a file at their end.
This is because the beeping might screw everything up--
although I suspect it may be OK if both of you are using
modems with MNP 4 or better.
A //G may be typed at the start of any line to toggle active
grammar checking from ON to OFF, and vice-versa. The "G"
must be in upper case.
See also: KEYS.HLP
Command Line Besides the commands below, auto-detect for ZModem and
BiModem uploads is also done. Doing an upload in the middle
of a message will not destroy the message, and it will be
saved before starting the transfer.
-40-
Users may set toggles to determine if the total number of
words, lines, and/or characters should be shown. Similarly
for time to enter the message and a Characters-Per-Minute
rate.
Editing by line number is much more difficult when the user
has "no-numbers message entry" toggled to ON.
% Save the message to a message file.
Only the sysop may do this. But there is a Toggle which you
can use to let Message-Op's do this also.
The message body is then stored in a MESSAGE.### file. Which
then can become part of other messages via the %%%###
command.
You could rename the file to something like MESSAGE.MJR, and
then just use "%%%MJR" anywhere in a message.
These are particularly useful if you have a fancy
"signature"--easier to do a quick "%%%xyz" when entering a
message at the end of a message than a complex signature.
When we export the message to .QWK or via net mail, these
"%%%"s are expanded out first.
Abort Aborts the current message. No message is sent.
If you entered more than 80 characters or so, you will be
asked to confirm that you really want to abort the message.
Continue This lets you continue your message from the point where you
entering left off.
Delete lines Use this to delete a line or a block of lines from your
message.
Edit This option will search for an exactly matching string in the
message, and replace it with another string you supply.
This is the command to use for fixing up typos in the
message.
Finish later This will save the message as a special "I want to finish it
later" message.
What this means is that when you (the author) again read the
message, you will be able to "Continue message". Selecting
this option will let you continue the message, edit it, etc.
just as if you had never stopped.
-41-
After saving, the author can still (or not) upload any File
Attaches if they wish.
The message is saved--and actually sent. If the receiver
logs on before you have finished (at a later time or date)
then they will see it as a completed message.
In theory, anyone could just use this instead of Save to save
all their mail. Then later modify what they said in the
message, and proclaim "that is what I said originally". The
defense for this is that the original message's text will
appear as orphaned text when you purge.
This command is not available if the message has CC's.
Grammar check This does a spell check on your message, and offers you the
opportunity to correct the misspelled words.
When a word is not found, and the user hits [Enter] when
asked for the corrected spelling, that word is put into your
WORDS.NEW file. This file will be utilized in the future
when I add the ability to update the WORDSx.DAT files.
While it is checking, hitting [Enter] or any of the valid
entering messages command keys will bring you back to the
command line.
Insert lines Use this to insert text into your message.
You will be asked which line number to insert before, then it
will allow you continue using the normal message entry
system.
You can insert into quotes to produce the "quote-reply-quote-
reply-quote-reply" type of message.
List This lists your message, including line numbers.
Colorization codes are not acted upon, but simply displayed.
While it is listing, hitting [Enter] or any of the valid
entering messages command keys will bring you back to the
command line.
Preview This displays your message exactly as it will be seen by
others when reading it.
Colorization codes are acted upon.
None of the reading messages commands will work, although "?"
will still bring up the help screens.
-42-
Save This compresses and saves the message.
The software has the ability to maintain a text file of all
messages added to the Message Area (see Message Area
Attributes to turn it on/off). When the message is saved, it
will be appended to this file. This feature is useful for
providing a way for whole message areas to be downloaded or
FREQ'd (rather than using the Message Downloading/.QWK
system).
-43-
MESSAGE FILES Using an editor (or the "%" command) you, the sysop, or
whoever you designate as the Message-Op (for an area) can
send messages that include a special "load message file"
command. This command, "%%%" when embedded within a message,
will cause the software to search out a file and load it into
the message when reading.
Message files start with the name "MESSAGE." and contain a 3
letter extension ("xxx", so "MESSAGE.xxx"). It provides a
method of sending lots of identical letters while using a
minimum amount of drive space.
Basically all these message files contain is text. You may
create, or alter, these files with any standard text editor.
Even put in ANSI codes.
Usually, though, you will just create the message and use the
"%" command to save it to a file. With this method, the
computer increments file extensions ("###") from the highest
found (example: if you have MESSAGE.009 then MESSAGE.010
would be created). However, you may re-name these extensions
to any three characters you like.
Message files should not exceed 8,192 bytes in size. To do
so is risky since it relies on string space.
Inserting a message file into a message is simplicity:
"%%%xxx" anywhere inserts the message ("xxx"). They do not
need their own line. They can be in the middle of a "word":
"You should%%%xxx.". They can be recursive--the file
messages may contain "%%%" codes themselves--warning, the
system does not protect you from looping, which will crash
the system (looping: xxx contains reference to xxx, or xxx
contains reference to yyy and yyy contains reference to xxx,
etc.)
The system only expands the "%%%" codes into messages if the
message was sent by: the AI, the Sysop, or the Message-Op for
the area. Any other authors and the reader will see
"%%%xxx". Similarly for message files that are not found,
"%%%xxx" gets displayed. This allows you to use "%%%%%%%%%%%"
without worrying, and users cannot find out your message file
contents, nor use them in their own messages.
Mass Mail uses these to send letters to users of a defined
Security Level value. You also use this to configure a
message to be sent to new users (to introduce them to you,
the BBS, and the interface).
There is nothing stopping you from creating the messages on-
the-fly and just using the "%%%" codes instead of re-typing
large blocks of text.
-44-
The "%" command lets you use the message entry system as a
text editor. However, remember that messages are divided up
by "paragraphs"--a paragraph is text followed by a CR/LF (an
[Enter]). Remember, text is word wrapped. So if you edit
the file, you will probably see lots of lines that extend
past column 80. If you do choose to edit messages
externally, I recommend only using CR/LF's where necessary,
let the software do the word wrap (really, you just need to
follow the same advice as Uploading/Importing a message
uses).
Normally only the Sysop and the AI may send messages with "%"
codes. However, you may change a Toggle to also allow all
Message-Op's to also send messages with "%" message file
codes.
%%%LOK is a special order. It will set the user's locked-out
attribute, so that when they are done reading messages, they
will be hung up on and locked out of the system. The
"%%%LOK" command is ignored until the name logged in matches
the TO: field of the message. This allows you, or anyone
besides the person the message is to, to safely read the
message.
With any "%%%xxx" command, three stages are done: first we
see if there is a MESSAGE.xxx file to display, if there is,
then we show it. Second, if no MESSAGE.xxx file exists, we
see if it is a special command, if it is, we do the command
if possible. Lastly, we simply display the "%%%xxx" because
we cannot do anything with it.
A serious draw back with this: one can never remember which
MESSAGE.xxx contains what. In a future release, I will
extend this to support "%%%pathname".
See also: SETTINGS, TOGGLES
-45-
RAMBLINGS Ramblings are both message files and text files. They
contain messages stored in text file format.
Users append messages to the end of these files.
Unlike regular message bases, however, these utilize the same
NewFilesPtr system as files do. After each logon, all
formerly new ramble entries become old.
Anyone can add to a ramble.
Anyone above a defined SL may create a ramble. The creator
may even restrict access to the ramble by a SL (SL
restrictions higher than that of the users own are not
accepted).
Only the creator of the ramble, or the sysop, can delete a
ramble.
Any ramble files containing new entries are highlighted.
Technical note: Ramble file information is stored in
RAMBLING.DAT, and ramble message text is stored in RAMBLE.###
(001 to 996). More than 996 will merely overwrite 001.
While a user cannot upload a message in file form (like they
can with the message system) they can do an ASCII send from
their end to send up a prepared message.
The ramblings menu has a statistics/title toggle option. The
statistics are useful for finding new messages if you have
not checked in on the rambles after a few calls.
When reading rambles, you can elect to read the whole thing,
just new entries, or jump past a specified number of entries
before reading.
Rambles are meant to be foot-loose-and-fancy-free. A wide
open system for quick exchanges along a single topic. It
works best if you give can-create-rambles access all users.
See also: SETTINGS
-46-
FILE AREA There are two ways to list files in the File Areas: the
CONTENTS normal paged system, and a Point & Shoot system.
LISTING
File areas to which the user does not have access are not
shown. The area numbers (1..n) that the user will see is
adjusted properly (if you have 4 areas and area #2 the user
has to-low a Security Level value for, they still see 1, 2,
3, not 1, 3, 4).
Paged System What I reference below as "the file system" is that part of
the software where files and descriptions are displayed for a
File Area, and which users may select to download.
This section does not deal with the commands to get you into
the file system, merely on the file system itself.
Firstly, you must remember that the file system is far more
powerful than any other ever invented.
Most BBSs are happy just to display a FILES.BBS file that is
stored in that File Area's directory. This software's file
system not only lets you seamlessly fold multiple directories
into a single File Area, but it lets you define both the File
Area header and how the file description lines are to be
displayed. These too are covered in other areas of the docs.
In the file system, the AI does a lot of management for you.
Discovering and removing and fixing file entries. It tells
you what it is doing at the top line of the screen (only the
console see's this). So powerful is it, that you could
scramble all the files on your HD--putting them randomly into
different areas, and (after listing all the areas) your
entire on-line file lists would again be 100% accurate. When
it discovers a file, use uses the AI face for uploaders name.
But don't worry about this, it's automatic.
The display As mentioned you will be able to configure the header line(s)
and the description line(s). You will be able to do this for
each area individually if you want. This is explained later
in the docs.
Right now, I want to cover some of what you will see.
The number of lines of files/descriptions displayed depends
on the users defined screen size. As usually, if you did not
start the program with /USEVGA the screen may look weird on
the console when the user has a > 25 screen size. Just
ignore that.
Files have a file selection letter displayed next to them.
This is "A" through "Z". If we reach "Z" before we fill up
-47-
the screen, we stop displaying entries at that point.
Example: this happens a lot with GIF areas and > 25 screen
modes because GIFs usually only have one line. For normal
File Areas, enough of the files have extended descriptions
that this rarely occurs. This method was considered better
than using numbers (1 to 50).
When displaying the last file, if it has a long description
that doesn't fit, we display what we can, and when the user
goes on to the next screenful of files, this file will be the
first one, and it will have its full description displayed.
This method was deemed better than not displaying the file
(leaving blank lines at the bottom) or truncating the
description and not displaying it on the next page.
New files are automatically highlighted to bright white.
If a file has some Attributes, they are displayed using the
following four letters:
f appears if the file is free.
g appears if the file is a group-specific-only file.
i appears if the file is invisible. Only the File-Op or
sysop will see the file entry.
p appears if the file requires a password to download.
When listing "new files", the files are sorted newest to
oldest with the newest one being on top. They are also
displayed by area.
When listing for files containing a search string, they are
listed newest to oldest (newest at top), and in a single-area
like format. The display uses area #1's defined Form Type.
Command line There are usually just two command lines, one that says
"Option, ?, or [Enter] to move on:", and some question asking
for a file name.
During many of the options below, a user may type the single
letter rather than the filename for files that were listed on
the screen. They may also enter file names for files that
are not displayed, and in any File Area to which they have
access.
From the main command line:
"?" will bring up a list of commands.
-48-
[Enter]
will display the next page of files, or, if at the end, go
to the next File Area and display its first page of files.
<up>/<down>/-/+
can be used to redisplay the files either moving down one
file or back one file
<left>/<right>/<bksp>/<tab>
does the same, but instead does it a page of entries at a
time.
You may also simply type a number, and we will jump to that
area and display its contents. Including the number of the
current area, for which it will simply restart drawing from
the start.
Auto-detect of Zmodem and BiModem uploads is also done.
User commands The following is a list of the commands anyone may type. For
the most part they are self-explanatory.
Quit
Stop listing files and exit the file system.
If the user has anything waiting in the download queue,
they are asked if they want to download it.
Next Area
Moves the user to the next File Area to which they have
access.
If we are at the end, we exit the file system.
If the user has anything waiting in the download queue,
they are asked if they want to download it.
Previous Area
Moves the user to the previous File Area to which they have
access.
If already at the first area, we just restart and list that
area again.
Redraw
This command simply redraws the screen. Useful if it gets
too cluttered when adding files to the download queue.
-49-
Extended File Info
This turns on the showing of the extended file information
lines. These lines are usually one or two lines for each
file that contains information such as who uploaded the
files and the date it was last downloaded.
Some File Forms do not have extended information lines, but
you can always add/change them yourself.
This is a toggle command, and when selected it will redraw
the screen. It is kept ON until you go to another area, or
again toggle it OFF.
Work On Archive
This will let you access the contents of archives.
Things you can do include:
List the contents of the archive.
Display text files in the archive.
Download files from the archive (user ratios do apply).
Test the integrity of the archive.
List From A Point On
This is a very useful command when there are large numbers
of files in an area.
It asks you for a letter, you type one, and it starts
listing the files in that area from that letter on.
Upload
This will let the user upload to the current area. If the
area does not allow uploading, it will try to let them
upload to area #1 instead.
After the upload, we return and redraw the screen.
Add To DL Queue
This command lets users add files to the download queue.
The current contents of the queue are displayed, and each
file they add is also then displayed.
Their current can-download bytes and minutes is also
displayed, and shows how much is left based on the current
files in the download queue.
-50-
The size of the users download queue depends on their
screen size, and once the screen is full they are not
allowed to add more files.
It does not do automatic helpful exchanges for minute-
credits or megabytes (like the menu Download command does)
when the user tries to exceed one of the download limits.
Contents Of DL Queue
This simply lists the contents of the download queue.
If there are files in it, the user is asked if he would
like to remove any.
Download
If the download queue is not empty, we first ask them if
they would like to download that. If yes, we send it to
them, then redraw the screen.
If they do not want the download queue, or it is empty, we
ask them them which file they wish to download. We then
send it immediately.
When we download the queue it is then cleared. This is
done even if the user aborted the download inside the
transfer protocol.
Xtra Info
This will display whatever information we have on a
specific file. Including: uploaders name, date it was
uploaded, actual files date, any attributes (expanded out)
and other stuff like number of downloads and date last
downloaded.
Sysop/File-Op The following is a list of the commands only the sysop, or
commands the File-Op of the area, may type.
"~" to Remove 1st Line
This is a handy command. It asks you for a file name, then
removes the first description line from that files
description. Particularly useful if you allow users to
enter descriptions for files with .DIZ's.
"!" for File Maintenance
This will edit the header information of the file.
-51-
While editing, the fields are "live"; changing the name
will change the file's name, changing its File Area will
move the file, setting the delete Attribute will delete it.
This command is a bit cumbersome, and I'll be cleaning it
up more in the future.
"*" to Oust The File
Deletes the file. Moves the file name and the first line
of the description to ALSO_GOT.LST. If the file is in a
"CD" area (File Area Attribute 9 ON) then the filename.ext
is added to your EXCLUDE.LST.
"@" to Oust The File: Special AKA
This is the same as the Oust above, but will create a
special ALSO_GOT.LST log line.
Specifically, it brings up:
FILENAME.EXT aka for:
and leaves you just after the "for:" to input something, or
zap the line and make it what you want.
I use this "aka" system for duplicate files. Files that
have been uploaded that actually have another name, and for
older versions of files. It helps keep the ALSO_GOT.LST
file lets cluttered and lets me know what this file was an
AKA for (I usually just input the file name to which this
file was an AKA).
Example: CSHOW460.ZIP aka for: CSHOW462.ZIP
CSHOW.ZIP aka for: CSHOW462.ZIP
VIEWGIFS.ZIP aka for: CSHOW462.ZIP
etc.
It provides me with confidence when looking at an AKA'd
filename that yes, I made sure it was a duplicate of
something else before I deleted it. Versus simply deleting
it out of hand (for which I may later come across it again
on a future CD, and again have to check it and find it was
a duplicate, etc.--this saves all that work.)
">" to Move File To Area
This command lets you move a file to another File Area.
Since remembering lots of File Area numbers is tricky, you
can do "?" which will bring up a list of your file areas.
This list may be paused with [Space] and aborted with
-52-
[Enter]. It is another thing that needs more work in the
future.
See also: MENU COMMANDS
Auto-delete This software's "auto-delete" capability is curse because it
curses works so damn well!
Whenever you are in DOS, you can delete files in a File Area,
or move the file to another File Area, right? For example, I
like to exit to DOS to look at the GIF's, and then toss them
into the various GIF areas myself.
Upon return to the BBS, I simply list the uploads area, and
the GIF areas. When I list the uploads area, it auto-detects
that those files (GIFs in this case) that I moved/deleted are
no longer there, and it sets their "deleted" attribute. Then
when I list the GIF areas, it discovers those that I moved,
and "undeletes" the entries.
Its simply a lot easier to delete files in DOS when I need
more drive space, and let the software auto-fix the File
Areas for me.
But the dark side of this is that the software does not do
two things when it auto-deletes a file entry: it does not
remove the entry from FILES.IDX (so if you type in the
filename.ext it will still "find" it), and it does not record
an ALSO_GOT.LST log entry.
We do not do these two things because they take a lot of time
(particularly with lots of files being moved) and because the
software really isn't sure that you deleted the file (you may
have just moved it to another directory, nullifying its work
to do the above steps).
The first thing, the FILES.IDX entry, is no biggy. If you
pack your file entries this cleans it right out--so its rare
a user will try to download a filename.ext that is no longer
on-line.
The second is a problem only if you like your ALSO_GOT.LST
file to be accurate--and I do--since users can properly
proclaim to have searched the lists, not found the
filename.ext, so shouldn't be penalized at all for uploading
the non-duplicate duplicate. Although, in a twist of irony,
the dupe checker will probably identify it as a duplicate.
To get around this logging problem, whenever a file entry is
auto-deleted, we wait until we pack the files then we record
the ALSO_GOT.LST entry.
-53-
Thus, if you do somewhat regular packing operations, you
should be able to avoid any troubles.
Point & Shoot Unlike the paged system above, the P&S system does not do any
File Selection "correcting" of errors it finds. It does not list files that
and are <incomplete> or invisible. It does not highlight new
Information files. It does not display extended descriptions. It does
System not do automatic helpful exchanges for minute-credits or
megabytes when the user tries to exceed one of the limits.
The P&S system also only does about 1/2 the commands, and the
number of files it can display from the File Area is limited
to the users screen size.
Most of these deficiences will be worked out in the next
release.
But basically what the P&S system offers is a point & shoot
system where one can tag and untag files easily, get a good
overall view of a dir, and in general be pretty efficient.
Movement is simple enough: either the arrow keys or number
keys (keypad with "Num Lock" on).
To move between file areas use "+" to move to the next file
area, and "-" to move to the previous file area.
To download files, you must first "tag" them. This is done
by hitting the [Space], [Enter], or "5" keys. Tagged files
can be untagged similarly. As you tag files, you will be
given a summary of how much and how long your download
session will be.
Hit "/" to turn on the description line. This will give you
the descriptions for each file as you move over the file
names. Hit "/" again when you want to turn it off.
Hit "?" to just give the description for a single file. This
is much faster than "/". If "/" is active and you hit "?"
than "/" will be turned off also.
Use "d" to download the files you have tagged. Unlike the
normal download menu option, this one will not do automatic
exchanges to help you out, nor does it offer the option of
auto-logoff.
Use "u" to upload. Auto-detect of Zmodem and BiModem is also
done. Unless you do not have access, or the current area is
not set up as an upload area, all uploads will go to the
current area. Otherwise an attempt will be made to put them
in file area 001--if still no access, then you will be
rebuffed.
-54-
"v" will allow you List/View/Test/Extract from that archive.
"q" will quit you out of the P&S system.
The software maintains a global download queue. The P&S
system interfaces this directly. The paged method has
commands to use it. There are also menu commands that let
you access this global download queue from menus.
-55-
DOWNLOADING Downloading (and uploading too) requires a protocol driver.
Usually DSZ.EXE (which provides many protocols, including the
commonly used Zmodem protocol). This can usually be found on
any BBS, or just ask the sysop of any BBS to give you a copy
if you do not already have one.
Users start out with 1 upload byte and 1 download byte--this
allows them to get to know the Download system--otherwise
they would just get "ratio out of balance, UL first", which
isn't quite as enjoyable for their first call to your BBS.
The caller will not be able to download if any of their
ratios are out of balance. This includes: bytes, files, and
post/call ratios.
At the downloading screen, callers are only able to enter
file names until they reach the end of the line (4 or 5 file
names). To do larger "batch" transfers they should use batch
downloading when listing File Areas. Wildcard's are not
allowed. I have plans to expand this.
Technical note: Since the wanted-for-download file names and
paths are sent to a file, whatever protocol we use must be
able to read in this file. The protocol must accept
"@filename.ext" at the end of its command line (where
filename.ext is our list of file names-currently it is named
FNAMES.CTL).
If the user selects auto-logoff, and at least one file was
not sent, then auto-logoff is ignored and the user is
returned to the system. That is, if auto-logoff is desired,
then all files must have been successfully transferred before
it will take effect.
When downloading, either bidirectional or regular, the
software will, through exchanges, try to meet their wishes.
If they wish to download a file, and do not have enough time,
but plenty of download bytes, and exchange is done for them,
giving them enough time, with reduced bytes (if it is
possible)--essentially saving the user the trouble of doing
with Exchange. Exchanges are not done with regular "daily"
minute allotments, but with minute-credits. This is not done
with the batch downloading system.
Similarly for bidirection. Except the exchanges usually
occur after the transfer. If the user exceeds their time
allotment, then exchanges are done until they are OK again--
this can mean "borrowing" against the future (negative
minute-credits). Should a user with negative minute credits
(and few or no download bytes) try a bidirectional protocol
again, he will have it limited to whatever his current
download minutes are. Should his negative minute credits
-56-
exceed his daily minutes allotment, then he will not be able
to use the bidirectional protocols at all--indeed, he will
not be able to download either, only upload.
Abuse: It is possible to abuse the system by just logging
on, using a bidirectional protocol for three hours of
downloading, then logging off and repeating it with another
name. For this reason I urge you to restrict bidirectional
protocols to users of levels greater than your first ("new
user") level. With "validated" user levels, no abuse is
possible because ratios are always maintained--even if means
that the user had to go into debt. Any imbalance "abuse"
(such as doing three hours of downloading) will be handled
the next time the user tries to download. The system is
designed to be flexible, but a user who tries to abuse the
flexibility will, sooner or later, run into a wall--which
will require an upload.
When a user downloads a free file (as denoted with an "f" in
the file listings), the time and size are not counted against
them, and do not appear in their stats at all (it is as if
they never did it). It does, however, appear in the log
files (callers and summary). This is true even if the
download is aborted midway.
When a download is not completed, bytes are not subtracted
from the user's totals--they are only subtracted when
downloads have been completed. While on the surface it may
seem like abuse is possible (download 90% of the file and
extract the remaining parts with "Work On Archives"), in
reality it is too much work for a user to consider it
worthwhile (they must use PKZIPFIX for ZIP's, they must take
time to calculate where to stop, and if they screw up, they
must repeat the whole process). I think only one user in two
years of operation ever attempted this--I just manually added
the bytes to his record, he never did it again. Uploading is
much easier to do, and the user needs to have the stats to
download the whole file in the first place to even start the
transfer. Finally, the Exchange system allows users to
maximize their file stats for need: time or bytes--which also
has the effect to eliminate complex download abuse.
Free downloads using the "FREE" menu commands do not take off
time, or bytes. Potentially a user could just do a large
free download all day to tie up your system. If this occurs,
just make the free file download menu option with an SL
higher than that of new users.
Ultimately, if you find a user is trying to abuse your
system--tying it up, calling and hanging up, etc. Calling
the phone company and complaining about harassment is the
best way--as the phone company has the calling logs and will
-57-
be able to see who the caller really is, and prove the
pattern of abuse.
Password protected files are handled two ways. When the file
name is typed at the downloads-file-name-entry-line they are
allowed, when the user completes their entry, then the
question regarding the password is asked, and they are only
allowed to download it if successful. BiModem does not care
about our internal password system, it has a system of its
own with its own password file, you must put in these entries
manually for BiModem to protect your password-protect files
and your invisible files (since a user can find the name of
an invisible file from the callers log--for long-term
invisible's, short term invisible's have a low chance of
being seen and are not worth the trouble). This is only for
on-line files in the File Areas, other files on your disk are
always protected from downloading.
Normally, SL protection is done at the "get file name" part
of the operation(s). We check DL SL for the File Area the
file is in, if not enough access, we pretend it does not
exist. However, BiModem has no method to stop a user
requesting any file from any of your "BiModem-accessible"
defined areas (done with BIMODEM.DIR). Rather, what the
software relies on to do this is for you to limit access to
the BiModem protocol itself to only those users who can
access all your file areas already.
Downloading messages (with "Message Downloader") and
downloading a Master List (using the internal Master List
downloader) are also free downloads (no bytes/time taken
off). The why is obvious: its faster than if the user did
the same on-line, and therefore should be encouraged.
If a user has their "all downloads are free" Attribute set
on, then all files are free and no byte/time information is
recorded or taken off.
You can set it so each download gives the uploader a
"commission"--a percentage of the files value.
-58-
UPLOADING When a user uploads a file, they are given minute-credits and
byte-credits. Both of which are exchangeable for the other.
Minute-credits allow more time for downloading, and byte-
credits allow more bytes for downloading.
Minute-credits also allow more time for door games.
You may postpone the giving of these credits until after you
validate the file if you wish. Or you can credit them a
little at a time--it's all in the Settings (and/or also in
the Protocol setup's).
You may only have one file on-line with the same
filename.ext. If the user uploads a file with the same name
as one that is already on-line, this is known as a duplicate.
They do not receive credit for uploading duplicates, but they
will be shown a note that they should leave you a message to
get credit. Then, if the file is original, you should rename
it, and manually give the user their UL bytes and minute-
credits for the upload. Whether your BBS renames,
overwrites, or rejects duplicates depends on your protocol
and what protocol parameters you use. But in its default
settings, we give the file a new name, like FILENAME.ZI1.
Normally, uploads will be given a "9" for L&D value, but
Targeted uploads are given only a "2". If you disable the
L&D system then this does not matter.
Abuse: the only possible abuse involves logging on with a
phony name, uploading some duplicate junk, downloading what
they want, and then next time doing it with another name.
This can be avoided by having a complex new user/access
procedure, or just requiring uploads to be validated by you
first.
If a user relies on auto-detect ("just does it") for their
upload (for instance, at an ANSI menu), then we will first
try to put that upload into the current file area. If no
access, we try area 001. If the user does not have upload
access to area 001, after not being able to put the upload in
the current area, the upload will not be allowed to take
place.
After a upload is done, there are a variety of post-upload
processing that can be done. Including: insertion of BBS
comments into .ZIP and .ARJ files, extraction to a file of
.ZIP comments, extraction of .DIZ descriptions to your
reviews files, and running of a virus checking program.
These are registered features, however.
See also: SETTINGS, TOGGLES, Protocols, Executable Lines
-59-
Searching When a user selects a non-bidirectional protocol, they will
be asked to enter a search string and a "search the off-line
lists" will be done. It is the user's responsibility to make
sure the software they wish to upload is not in your lists.
You may toggle this requirement (that they search before all
uploads) ON/OFF.
When searching the off-line lists, a text search is done--not
a file name search. When a user enters a string to be
searched for, some processing is done: see "Search string
chopper" section. These choppings will be shown as they
occur--slowed down so the user can see it.
If uploading (not when doing the menu command to search the
lists), if they hit [Enter] before a search is completed,
then it is assumed they do not want to upload, and are exited
back to the menu. They need only one completed search in a
series of searches to move on to the next step and upload the
program. This prevents someone from searching part of the
search file, but not all of it. Needed, because the file
they wish to upload may be in that part of the list they did
not see. If they know the file is not in your list, they can
just enter a "scramble string" to do the fastest search
(example: AJKLK).
The File Area Attribute for "don't include in Master List"
also affects the searching of lists when it searches on-line
lists (since it uses MASTER.LST)--so you should add the text
file of your un-master-listed areas to the search off-line
list database as well. Usually, however, you only turn
"don't include in Master List" off for transient areas (such
as CD's you swap in and out each week, etc.)
File Minute-credits will not be given until the user enters a
Descriptions description for their upload. This may done later via the
Add File Review command. Using the file name as a
description is ignored. Holding back of minute-credits is
the punishment for users not using descriptions. This
software is designed to reduce your workload. If a file has
a FILE_ID.DIZ description file, this is considered an
acceptable description and they are given credit.
Users who have a SL greater than the lowest SL you have
created, may use "/" or "\" as the first character of the
description to make it a "sysop-only" file. This makes the
file invisible--only the sysop or File-Op will be able to see
it.
Once a valid description is given. The software will check
to see if the file is a ".GIF" or ".JPG" image. If it is,
then the dimensions are entered into the description. Files
which have a ".GIF" extension but are not really GIFs are
handled properly.
-60-
If censoring is turned on, then only the File-Op of a file
area may enter uncensored descriptions.
One problem that seems to confound users is uploading
multiple files (batch upload) that have different
descriptions. Since if they enter the description first, all
files are given that description. To make life easier on
them, you might want to add the text "you will be given the
chance to enter individual descriptions after the upload is
completed."
See also: KEYS.HLP
-61-
REMOVING FILES There are 3 ways to remove files: deleting them by hand,
deleting them with the "oust files" routines, and deleting
them by using L&D delete. The software never deletes on-line
files without a human to confirm it.
Deleting by hand simply involves using DOS's DEL command. It
is what you probably do to delete files on your hard disk or
floppies that you no longer want. When doing this to files
in your downloads areas, you should do it before starting up
the BBS. If you do delete a file while the BBS is running
(by shelling to DOS or through a door) then the BBS will not
know that you deleted it--some routines will still allow that
file name to be typed, displaying a "file not found", and
probably confusing your users. The software (eventually)
self-correct itself when it finds the file missing (when
listing File Areas).
The second method, "ousting files" via the two sysop menu
commands: Oust Files and Oust Files/Penalty, or by setting
the "1" attribute with File Maintenance, will delete the
file.
The difference between Oust Files and Oust Files/Penalty is
that Oust Files repeatedly loops asking you for files to
simply delete. Oust Files/Penalty asks you for a file name,
finds out who uploaded it, then asks you for a reason why
you are deleting it (corrupt, or a duplicate, whatever), a
message containing your reason and other information is sent
by the AI to the user, and finally the file itself is
deleted. The text of the AI's message can be found, and
edited, in LINES.TXT.
The third method is using the Life & Death system. When a
file's L&D count is at zero ("?"), and a variety of
conditions are met (see L&D menu command) then a user may
choose to "reduce" the L&D value further--delete it.
With any of these methods, the deleted file name, size, and
description, are written out to the log file and the
ALSO_GOT.LST file.
If you use DOS's DEL command, then the software will
recognize the files as missing and consider them deleted. If
you should accidentally delete a file, and then put it back
into any download directory, then the software will
automatically undelete the file entry for you. If you should
only change the extension of a file, the software will
properly handle that as well.
None of the above are as complex as they sound. I just
described in detail what happens. Everything is automatic.
When you use DEL you just type a file name. When you use
-62-
Oust Files, you just type a file name. When you use Oust
Files/Penalty, you just type a file name and a reason (I like
to keep mine to one word). With L&D delete you just type the
file name and a Yes/No confirmation.
When using the "Oust Files" command, you are able to enter
wildcards. When the software detects wildcards, it does
something slightly different: it sequentially goes through
all the file records deleting all entries that match the
wildcard. The purpose of this is to also provide the sysop a
means of eliminating duplicate filenames (which are not
allowed, and do cause troubles). Otherwise, without
wildcards, the software merely deletes the first entry it
finds that matches that name. Such as for removing FILES.BBS
after installing a CD with this file in each dir (you would
do an Oust Files with FILES.BB* as the file to delete).
-63-
MISC. When you get a percentage progress report: ▓▓▓█████ (30%)
Do not worry if it ends at less than 100%, it may end at 95%
if the numbers are "just so" and it may end up much lower if
there are not that many things to do.
If one gets "No messages found." when reading logon mail--
after having been promised mail ("You have mail in the
following areas..."), then this is not a problem. It is
possible the sender of the message sent it, but deleted it
later (before you called) or the system deleted it because it
was too old (if the Message Area maximum-messages circular
buffer is in effect) and you had not called in a long while.
But it usually occurs after you have already read your mail,
and then went on to somehow crash the BBS or used the <alt>x
command.
The RESULTS file will still contain my BBS's voting totals
and system statistics. Just run "update system stats" from
the sysop menu to eliminate it all.
The BiModem configuration files were included to aid in setup
of BiModem. You still need to go through and make sure the
path's and modem type are correct with BICONFIG.COM.
In File Maintenance, even though the password field for a
file is a number, the data entered must be a string. To
change a password, merely enter the password you wish. To
clear a password, merely enter a single space.
-64-
I AM LOST!?! If you have gotten to this point, and you have not tried the
software yet, you are probably really confused.
I have given you the architect's designs of the building, but
all you want is the front door, elevator, and location of an
office.
Run the program, see what happens, how it works, etc.
However, be aware that a lot does not show up until it is in
full operation.
In this initial configuration, it is a scaffolding--it may
even appear simplistic.
Do not think about what it is, or what it can be. Take
change a little at a time. Look over the stuff you do not
know only when you want, or need, to know it.
This is not a "BBS construction set"--although it can be.
You do not need to be a programmer--although you can be.
YOU decide how "deep" to get into this software. Laugh off
all the confusing stuff--it can be ignored, but it will be
there when you need it.
-65-
CUSTOMIZING You probably have an urge to jump in and start changing the
101 menu ANSIs and the menu commands.
Do not.
Your first step should be to customize the internal
structures of the BBS. This means using the sysop menu
commands: Change Settings, Alter Pathnames, Toggles, and
other configuration commands.
Indeed, Toggles should be your first stop--as it is the
easiest. Then Change Settings. These modify the limits of
your BBS.
Believe me, I know it is complex, I must urge you to take
very small steps in your change-over of the software. Do not
read more into what you see, follow the examples, if I do not
say it cannot work--then you can probably do it.
See also: SECURITY LEVELS, FILE AREAS, MESSAGE AREAS,
CONVERSION
-66-
TOGGLES From the sysop or Waiting-for-caller menus you can bring up a
menu of Toggles to change.
Each option breaks down into a screen of Toggles.
The docs for the toggles have been put on-line as part of the
Toggle system.
Turning off the AI toggles really does make the software much
more simplistic (dumber). The AI actions were designed to
continue the work the users would otherwise have to do on
their own.
-67-
SETTINGS From the sysop or waiting-for-caller menus you can bring up a
menu of Settings to change.
Each option breaks down into a screen of Settings.
The docs for the settings have been put on-line as part of
the Settings system.
Changes take effect/are saved when you exit the main settings
menu.
-68-
PATHNAMES Selecting "Alter Pathnames" from the sysop menu brings up a
menu of the pathnames the software uses internally.
Each option breaks down into a screen of pathnames.
The docs for the pathnames have been put on-line as part of
the pathname system.
This is really only for experienced users who need/want a
little something special in the way their files are
organized. Such as having them spread across a network. Or
to better optimize multi-node operations.
Be sure the pathnames you give are correct--as the software
does not complain when it cannot find a pathname. And the
errors you get may be subtle. But most sysop's do not have
to change these pathnames.
"???" expands to 3 letter node numbers (001 to 999).
"***\&" expands to Style\Language codes--used to separate
files by their Style and Language.
The pathnames displayed on your screen will always be the
"post-processed" pathnames. AFTER they had their "???"'s and
"***\&" changed. But when you change it, feel free to use
"???"'s or "***\&"'s if you want--they too will show up as
post-processed equivalents. In other words, where I have
"c:\bbs\node.???\" you will see "c:\bbs\node.001\" even
though it is really stored as "c:\bbs\node.???\". When you
actually edit it, then you will see the real thing.
-69-
MENU COMMANDS From the sysop menu, or with <ctrl>F2 from most anywhere,
you can access McEditor. The Menu Command Editor. More is
explained on this later.
Menu Commands are 4 letter commands (eg. "PagF"--case does
matter).
The docs for these commands are on-line inside McEditor with
the "H" command, or from most anywhere with the <ctrl>F3
command.
<ctrl>F2 and <ctrl>F3 also work from the waiting-for-caller
screen.
-70-
ANSI'S TheDraw adds blank lines to "fill out the screen" when it
saves ANSIs. You should use a text editor and edit these
files to get rid of those blank lines.
TheDraw might also declare some ANSIs "animations" when it
loads them. Ignore that. You always want to save your ANSIs
as: Ansi, Clear screen, No max line length, fastest output
speed.
You should not use the "«", or "±", in any ANSI's before you
get the callers name (all ANSI's before your "LogN" command).
These characters are used to tell the other computer when to
receive net mail--it may trigger a premature net mail
transfer before your BBS had planned. That is, if another
BBS calls your BBS looking for net mail, it is looking for
these characters--since the BBS sends out these characters to
tell the calling computer to begin a net mail receive. If
they appear in your ANSI's, it causes trouble. Once a user
logs in, then you can use the character in any of your
ANSI's.
Auto-detect of Zmodem or BiModem is done at all menu ANSI's.
For menu ANSI's, the who's-on status line is displayed on the
next line following the ANSI--so it is not recommended you
have menu ANSI's that exceed 23 or so lines. Also because
many communication programs use two lines to display
information as well. But if you do want to use the full
screen, just add a little jump code to jump up to a higher
line where it can display the sysop line.
If at a menu, and the user has called less than 4 times, then
if they hit [Enter] three times in a row, we bring up a
little helpful reminder that they should check that they have
wrap-around set properly. Even if your menu ANSIs do not use
wrap-around (ie, an ANSI that is one long line uses wrap-
around), this is a useful little thing to tell the user that
he's acting odd. Typically this appears if new users like to
hold down the [Enter] key after logging in.
See the "AnsQ", "ShwQ", and "EANS" menu commands for
information on ANSI InfoForms and Editable-ANSIs.
See also: ANSI.HLP
-71-
CONVERSION Some advice on converting from another BBS program:
Use the Import Descriptions command to convert file
descriptions.
ANSIs should not be any problems, although you will have to
match your menu commands with my functions. It is best to
phase this in one or two commands at a time. I have a lot
more commands than any other BBS program, so you will have to
do some extra work to put those additional commands onto
menus (although ignoring them will make things easier).
If you are currently using RemoteAccess, Renegade, FeatherNet
or SpitFire, then you can convert your users and messages
files with CONVERT.EXE. If you are using something else,
then use this program as an example, and modify it to suit
your current BBS's data structures. The Convert program is
entirely self-contained in standard DOS Basic. If you need
help, just ask me, chances are I will do it for you. If you
make changes, send me them so that others may benefit. The
convert program has not undergone a lot of testing--if it
does not work, tell me and I will give you a fixed version.
Telegard/Renegade and RemoteAccess seem to have a lot BBS
programs that use the same format (are rip-off's of these
rip-off's), they may be convertible as well. For some
others, it might be useful to use an intermediary conversion
step (for example, WWIV to RA to JDR_BBS).
-72-
MODEM SETUP You must have a fossil driver installed. Such as X00 or BNU.
The command line for X00 for most people is just:
device = x00.sys e
Your modem should be configured as such:
Modem echos data (usually E1).
Modem sound off (usually M0).
Result codes displayed (usually Q0).
Full result codes (usually X4).
Verbal result codes (usually V1).
Auto-answer off (usually S0=0).
DTR follows connection (usually &D2).
Carrier-Detect (CD/DCD) follows connection (usually &C1).
DSR is properly maintained (usually &S1).
So, usually ATE1M0Q0X4V1S0=0&C1&D2&S1 will do it.
For your fossil speed, you should try either 19200 or 38400
and see which works best for you/your system. There is no
"57600" speed for the fossil, but the modem makers like to
push this number to show how fast their modems really aren't.
Your best value will depend on how fast your computer is, and
whether you've got multi-tasking or not, and possibly how
noisy (electronic noise) your whole computer set up is.
As released, the software begins with defaults of 19200 for
the baud, and ATZ for the initialization string. You can
change these easily at the command line (JDRBBS.EXE /?).
For some commands, the computer goes into an infinite loop
(locks up) when you specify a port for which you do not have
a modem. Also, it may lock up if you have configured the
fossil wrong (particularly if you specified a baud rate your
modem cannot handle, since all your modem see's is gibberish
when the fossil try's to talk to it).
The following is a checklist for setting up your modem:
1. Do the X00 (or other fossil) command set up.
2. Put in your correct initialization string.
3. Change the communications port to that of your modem in
Settings.
For dialing, I assume ATDT, but you can change this in
SHORT.TXT. Search for "dt" and "dt1-".
The modem will show you what it is sending and receiving
while trying to initialize the modem (and when dialing or
receiving a call). If it fails to initialize, then it is
-73-
usually due to you setting up the fossil or your modem
initialization string wrong.
See also: LINES.TXT, APPENDIX J, SETTINGS, CONFIG, Q&A.DOC
Example Scenario: you've just gotten a brand new Viva 14.4K/Fax.
It's not configured for a BBS--it's not even properly
configured for calling BBS's.
The modem initialization string looks like so:
AT&FM0W2&C1&D2&S1%C2S95=2
It expands to:
AT&F M0 W2 &C1 &D2 &S1 %C2 S95=2
First, some background. When you get a modern modem, it is
configured with "MNP5" compression ON. You don't want it on-
-ZIP's don't compress any farther, and all it does is reduce
speed (example: 282cps at 2400 w/o compression, 240cps at
2400 with compression ON).
Also, this example modem is setup so that when you make
contact you get multiple lines:
CARRIER: xxxxxx (eg. CARRIER: 14400)
PROTOCOL: xxxx (eg. PROTOCOL: LAPM)
COMPRESSION: xxxx (eg. COMPRESSION: V.42BIS)
CONNECT: xxxxx (eg. CONNECT: 19200)
The CONNECT is the speed at which we told the fossil to talk
to the modem. The CARRIER is the speed at which we connected
with the other modem. The PROTOCOL is the type of exchange
beyond mere baud rate we do (eg. MNP5).
And it's all wrong. We want CONNECT to contain both the baud
we connected with the other computer at, and the protocol
used. Usually this takes the form "CONNECT 14400" and
"CONNECT 14400/ARQ" where the "/ARQ" is used to signify the
faster MNP connection. This "/ARQ" is useful in the CONNECT
strings database for getting download-time estimations
correct.
Back to our string:
AT&F M0 W2 &C1 &D2 &S1 %C2 S95=2
&F tells the modem to start fresh with the factory
defaults.
M0 tells the modem to keep its speaker quiet.
-74-
W2 tells the modem to display "CONNECT <baud>" and
none of that other stuff.
&C1 tells the modem to tell us about the carrier's
status (DCD).
&D2 allows us to use DTR on->off to hangup the phone.
&S1 tells the modem to properly show us DSR status at
the WFC screen.
%C2 tells the modem to not do MNP5 compression.
Keeping v42bis compression is OK however, it's just
MNP5 compression that's bad.
This changes from modem to modem, see MODEM.HLP.
S95=2 tells the modem to add the "/ARQ" to the CONNECT
strings if we have an MNP/etc. connection.
This changes from modem to modem, see MODEM.HLP.
The above can be used as a modem initialization string, but
it's easier to do the following:
ATM0W2&C1&D2&S1%C2S95=2&W
and then use ATZ as the initialization string.
This example setup string will probably work for most 14.4k
modems.
Learning to use the &W command (then using ATZ) is a must if
your modem initialization string is too long to fit in the
configuration field. If this is the case, also check your
modem manual, many of the above commands are already the
default.
CONNECTs DB When your modem returns "CONNECT <something>" we rely on our
CONNECT strings database to tell us what <something> is (and
what it is to be displayed as). You can change these
entries, but they should satisfy most modems. See the sysop
menu for access to this database.
The CONNECT strings database is divided into three fields:
The actual CONNECT strings as the modem sends them, the
maximum CPS rate that that connection yields, and what to
show for that connection (for Last Few Callers and when
downloading).
When a call comes into the software, the database is scanned
for a string that matches what the modem sends. If none is
found, then the phone is hung up, and a "non-user" log note
is made.
When putting data in the "show user" fields of the CONNECT
Strings database, you should endeaver to make the entry such
that the first thing in the field is the actual baud rate.
Example: "14400 ARQ" is OK, but "ARQ at 14400" is not. The
-75-
reason is that doors and some other functions use the baud
rate, and expects it to be first.
Throughput When displaying text/ANSIs we first blast the output to the
screen, and then to the modem. This provides maximum
throughput and gives the modem the best compression options.
But what this means is that an ANSI could take a few seconds
to display on the users end while you're looking at it on the
console (if they have a 2400 baud modem for example).
Modems themselves have small buffers. But you might be able
to increase throughput farther by specifying a fossil buffer
as well: device = x00.sys t=2048 e
for example would specify a 2k output buffer.
File throughput is handled by your protocol drivers, and they
can vary widely.
-76-
TERMINAL This is invoked from the Waiting-For-Caller screen by using
PROGRAM the <alt>d command. A terminal program is a program used to
call out to other BBS's. The word "terminal" comes from
"terminal emulator" because that's what you're doing when you
call another BBS: emulating a terminal (in this case, a VT100
or VT102).
From there you are presented with a screen. It has a command
line, and if you just type something and hit [Enter] that
something will be sent to the modem.
On the other hand, if you use the arrow keys you will move
into the dialer part of the screen and be able to edit and
dial phone numbers.
Type "?" for some on-line help.
Hit <esc> to exit <alt>d and return back to the Waiting-For-
Caller screen.
Dialer The dialer system works a little different from normal
dialers. Instead of scrolling through one long list, you are
limited to the 21 lines you see. But what the software does
is let you add more entries by "depth". That is, when you
hit <ins> to edit an entry you can either create just a
normal dialing entry, or you can create a topic entry.
A topic entry is a link to another screen with 21 slots.
There is no limit to how "deep" you can make entries.
This system allows you to keep your most used numbers on the
first screen, and put less-used (but organized) entries onto
the other screens.
The phone number field is to be exactly as you want to send
it to the modem. For example, 1-414-643-1576. However, you
can optionally specify a "+" after the phone number (eg. 643-
1576+). This "+" tells the software to go into 50 line mode
when you call that number.
Command Line It is a simple "do what" question. You may either choose to
send a command to the modem directly, or use the "d" and "n"
commands.
"dt xxx-yyy-zzzz" would be to call another computer.
"d xxxx" will search your Dialer entries for one containing
the string "xxxx". It will then dial that number. If more
than one is found, it will ask you which one to use.
-77-
"n xxxx" works like "d xxxx", but the "xxxx" is a net
address, and the software checks its nodelists and retrieves,
then dials, the phone number for that address.
Note: if another BBS wants to put you through call-back
verification. You should do an <alt>p just before they call
you back. This will let you handle the RING, ATA, etc.
without having the incoming call confused as a caller to your
BBS.
Misc. The internal terminal program included has a lot of features
found in the better stand-alone terminal programs:
IEMSI support
This is a type of auto-login which is handled automatically
between the BBS and the terminal program.
You first define for yourself up to 3 different IEMSI
identities with F5. Then for each dialer entry, you tell
it which one of the 3 are to be your IEMSI identity. If
the BBS supports it, you save some keystrokes and login
faster. If not, nothing happens.
Note: your password in the dialer entry must be the same as
the BBS expects for IEMSI to work.
Arrow key support
The software will properly send the arrow key codes when
you hit the arrow keys.
Please note: this does not extend to <pgup> and <pgdn>
support--which we use for Uploading and Downloading,
respectively.
<home> and <del> will send a <pgup> and <pgdn> code,
respectively. But this is not widely supported.
50 line mode
You can choose to switch to 50 line video mode. You can
do this after you are already connected as well.
Direct screen writing handles Internet ANSI codes
If the called Internet computer doesn't recognize you, just
type in "vt102" for your terminal type. We do some special
handling of the ANSI codes it will send to provide a proper
Internet display.
-78-
Smart buffer purging
When you hit a key, and there are a lot of characters in
the incoming buffer, we zap that buffer. No more waiting
for the contents of the buffer to display before seeing the
effects of your keystoke.
GIP VGA graphics
Like the BBS itself, when you call another BBS that
supports the GIP graphics protocol, you can get VGA
screens, etc. As of this writing, only other Juggernaut
BBS's support this public domain graphics standard.
RING detection
When at the command line, and the phone rings, it will
automatically exit <alt>d and accept the caller. Where
this is nice is for unattended file-transfer-then-logoff
sessions--that is, you do not have to wait for the file
transfer to end thinking you are required to hit <esc> to
exit <alt>d.
Post-Upload-Processing
After you hangup from another computer, if you had
downloaded any files into directories defined as your File
Areas, the software will automatically import them into the
BBS. Both creating new entries, and doing post-upload-
processing on them (getting .DIZ's, adding comments, etc.)
Files downloaded into non-File Area directories are
ignored.
Most files have .DIZ's, so we do not bother trying to ask
you to remember the description of the files.
Hit <f10> when connected to another computer for help.
When you have contacted another BBS, the following keys are
active:
<f1> toggles the trapping of all comm I/O to a file.
<f2> Send a file (ASCII send--no protocols). Can use
wildcards to send a random file from a bunch of
files. No stop/exit key handling is done.
<f9> toggle between 25 and 50 line screen modes. Note:
this does clear the screen when you do it.
<f10> quicky key help.
<pgup> to send a file. You must enter the full path and
filename of the file(s) to upload--wildcards are
OK.
-79-
<pgdn> to receive a file. After starting the transfer
just hit <pgdn>.
<end> to transmit any net mail meant for that BBS. If
you did not dial with "d string" or "n netaddr"
then it will ask you which net address to use.
Once hit, there is no way to abort <end>--since
the other BBS will now accept nothing less than a
mail attempt. This must, can only, be done before
you enter your login name.
<ins> this brings up the contents of NOTEPAD.TXT. When
a string is selected, it will be sent out as if
you typed it. Use a text editor to add/edit lines
of text in this file. If you change your mind,
<esc> will exit it--otherwise any key (such as
<ins> again) will send the selected text.
<alt>c this will clear the screen, and reset the screen
back to 80x25 mode. Mainly useful when using GIP
if for some reason you get stuck in graphics mode.
<alt>h to hang up.
<alt>l to "turn the tables". This allows the sysop on
the other end to log into your BBS as if it were
they who called you. If using JDR_BBS, then that
sysop must be in <alt>p mode. If using another
BBS program, then they must be in a "pure mode"--
that is, where they accept everything that comes
in, and do not send ANSI codes back out (example,
chat is not a "pure mode", when it changes colors
depending on who is "talking".). "Pure mode" is
also known as "raw mode" and "command mode".
<alt>s to shell to DOS. From the shell, you may use
something like LIST to examine the trapping file
(if you were trapping).
On some BBS's, you will be able to use <Control>S to pause,
and <Control>Q to un-pause (note, you may have to hit
<Control>Q twice).
Unfortunately, one of the most useful abilities of most
communications programs is missing: the backscroll buffer. I
do plan to add this.
-80-
CUSTOMIZING The single key to turn the BBS "on" is to change the comm
201 port in "Change Settings", to something besides zero (like 1
for COM1:). Answer "N" to the "Null port?" question. You
will need to already have the fossil installed and defined in
your CONFIG.SYS. Or you can just use JDRBBS.EXE /port=1.
When designing your BBS, there are three things you primarily
change: the menus (commands), the ANSIs, and the text.
You use McEditor to change the menu commands. Designing your
own commands or just moving around what is there. This is
explained farther on into the docs.
You use TheDraw, or some other ANSI drawing program, to
design your ANSIs. Your ANSIs are the primary "look" of a
BBS.
You edit LINES.TXT and TXT_BLKS.TXT to change the text that
is displayed. You have complete control over all text. The
words you choose provide the "feel" of a BBS.
You can customize each node differently, as well as have
different Styles\Languages available.
Besides the ability to put any commands onto any menu, there
are numerous ANSI smart-codes you can use to beef up menus
(or ANSI displays) even more. For a list of these, as well
as explainations of the ANSI codes themselves, see
HELP\ANSI.HLP.
The following files are where ALL text is hiding. Users,
however, only see text from LINES.TXT and TXT_BLKS.TXT. They
are all standard text files that you may edit using any text
editor.
IMPORTANT: When editing these files, you should completely
exit the BBS (and all nodes if doing a multi-node operation)
first, then edit. Do not edit them while shelling to DOS, as
the index pointers will need to be updated (otherwise you
will text start and stop in odd places).
LINES.TXT
See the LINES.TXT file itself for information on its
contents.
But mainly of interest to you is like 001. This contains
the often-used "general logo". When the software wants to
clear the screen, it sometimes uses this logo. So at the
very least, what you substitute in should clear the screen.
It provides a nice way to remind users what BBS they are
connected to, but can be reduced to just "[0;30m[2J".
-81-
When you see something displayed that you want to change--
perhaps a different wording--then search for it in this
file (and/or TXT_BLKS.TXT) and replace it with what you
want.
TXT_BLKS.TXT
Blocks are lines of text that have the same first two
numbers. Unlike LINES.TXT, which has its text
disorganized, this file has its text organized so that all
the strings for a specific routine are together.
When editing the text strings, %1, %2, %3, %4 act as place-
holders for data with some strings. This was done so you
could more easily edit a "whole string". As this tells you
how the data fits into the string, and in many cases allows
you to shift the order of display around.
Example: "%1 = %2, %3"
If the program normally displays: "Sysop = Rohner, John"
Then you could change the string to: "%1 = %3 %2"
and it would display: "Sysop = John Rohner"
That is, the %1's/etc. do not need to be in any kind of
order. In most cases, you can also drop a %# to stop the
display of the information, or add a %# to display
duplicates of information:
with the above changed to: "%1 = %3 the %1"
it would display: "Sysop = John the Sysop"
For those of you who work with C/C++, you'll notice that
this is very similar to the printf/etc. command.
SHORT.TXT
Like LINES.TXT. It contains a hodge-podge of strings.
Such as: the various censoring words, the phone dialing
string, and the <ctrl>Fx hot key definitions.
PRG_BLKS.TXT
Is a text block file like TXT_BLKS.TXT.
PRG_BLKS.TXT contains blocks only the sysop will usually
see: text for the sysop commands, and system-use blocks.
Almost always, this file will contain nothing the sysop
cares about.
SYS_BLKS.TXT
Is a text block file like TXT_BLKS.TXT.
-82-
SYS_BLKS.TXT is similar to PRG_BLKS.TXT, but it contains
stuff a sysop is slightly more likely to want to change.
DB_BLKS.TXT
Is a text block file like TXT_BLKS.TXT, but follows a rigid
design formula.
DB_BLKS.TXT contains DataBaser definition blocks. These
blocks describe the various databases to use with the
DataBaser system. You can add your own databases, but you
should not modify those already created. The DataBaser
system is described later in these docs.
See COMMON\COMMON.HLP for information on how the BBS uses
COMMON.LST files to determine when it should use a Language-
specific version of a file, or one in the COMMON directory.
LINES.TXT talks a little about its smart-codes, but these
codes can be used just about anywhere. Perhaps the two most
interesting ones are:
@pathname@ to display a file, and
&pathname& to shell and run a sub-program.
The HELP dir is also filled with subdirectories filled with
sample ANSIs.
-83-
SECURITY The software will allow you to work with Security Levels in
LEVELS the range of -32,767 to +32,767. Using negative values,
however, might not be recognized in some routines.
There are no "locked in" Security Level values that force you
define a specific value to a specific type of user. Users
may have any Security Level value.
You edit your Security Levels from the sysop menu command
"Security Levels" under Global: Users.
The software will either use their SL directly ("if SL < x
then ...") or indirectly ("if SL is > x and SL is < y then
..."). This allows you to use the Security Level system as a
"reward" and "punishment" system if you want.
I just use a simple six level scale (5, 10, 20, 90, 95, 100)
myself, but you can do what you want.
Important: When entering the Security Level data in the
Security Levels database, you must enter the values in
increasing order (for example, 5, 50, 500--not 5, 20, 10).
So that when done, your first entry contains the lowest
value, and your last contains the highest. The software will
make an attempt to sort any unsorted entries at the time of
input.
The highest (last entry) is assumed to be the Sysop level.
The second highest (next to last entry) is assumed to be the
Co-Sysop level. Since Co-Sysop's have a lot of the Sysop's
power, you should be careful about whom you wish to give this
SL out to. Even if you do not wish to have Co-Sysop's, you
must still create an SL value for one.
After adding/removing SL's in the SL's database, you should
run "Update Stats", or you will just get nonsense when doing
a "Stats Display".
Do not mess around with the security levels for message area
001, Private Mail. All users need to be able to access this
area, so your SL's for accessing this area should always be
equal to, or lower, than your lowest defined SL.
SL's (used in commands, etc.) do not have to be an SL value
in your SL database. Thus, if a command requires SL 10, and
you have defined SL's of 5 and 10, if you give a user 6
through 9, they still will not be able to access that SL 10
command.
Ghosting Some BBS programs use "user flags" as an enhancement to their
SL system. A user would have to have both the SL and the
flag(s) to do a command.
-84-
I have a system just as powerful. It is called "SL
ghosting".
It is simple: you have two security levels; one that users
see, and one that the program uses.
When at the SL database, the real security level is referred
to as the "SL value" and the security level the user see's is
referred to as the "show SL".
This allows you to give a user of, say, real SL 4 30 minutes
per day, and one of real SL 5 60 minutes per day, while
having both of them think they are level 5 because both SL's
have a "show SL" of "5".
But besides simple user limits, the real use for this is with
menu commands. Providing a way to separate your users
internally without them knowing about it.
EXAMPLE
┌───────────────────────────────────────────────────────────┐
│Your BBS has the following time guidelines: │
│ │
│ Normal user: 60 minute limit per week │
│ Donated $1 : 70 minute limit per week │
│ Donated $10: 100 minute limit per week │
│ │
│Then in your SL database: │
│ │
│ Real SL Show SL Free Minutes │
│ 10 10 60 │
│ 11 10 70 │
│ 12 10 100 │
│ │
│Thus you have three different limits, three different SL's,│
│but the users never know it--they all think they are level │
│10. │
└───────────────────────────────────────────────────────────┘
-85-
SYSOPS For message bases, file areas, and doors. The sysop of that
area is the one true sysop in that area--the real sysop being
just another user.
For most other things, when I say "sysop only", what I really
mean is anyone with a sysop-level security level.
Pay attention to some of the commands, they offer different
options and displays depending on whether the user is a sysop
or not.
Other stuff, like some time-out functions, work for whomever
is at the console.
Co-Sysop's A Co-Sysop is defined as being anyone with the SL defined
just before that of the Sysop's. Example: the sysop has 100,
and the co-sysop has 95. The co-sysop has many of the
abilities and views of the sysop.
Some of their powers:
- Can delete Questionaire entries.
- Can enter multiple spaces in a user name.
- No inactivity time-out.
- Can access any file in any file area.
- Can see invisible files.
- Views uncensored callers log.
- Reading messages:
User Maintenance
Edit message info
Kill file attaches
Send user -> PR
AI's go fish
- Undelete messages
- Delete File Area files
- Kill Ramblings
- FREQ files from other BBS's
- Delete users
Things the sysop can do that don't utilize pathnames on the
Hard Drive.
It is assumed that the Co-Sysop DOES NOT have access to the
sysop menus. Any commands from those menus are likely to be
the same type you would do for a File-Op/Message-Op (File
Maint, etc.) and should be put into a menu for the Co-Sysop
rather than letting him access the sysop menus.
File-Op's A File-Op is a user whom you turn over day-to-day control of
one or more File Areas to.
-86-
File-Op's do not have "sysop level" power. They are normal
users with extended powers.
Both the File-Op and the sysop always see invisible files in
areas under the File-Op's control. All File-Op abilities
only work in directories under their control.
When using List Unvalidated files ("LUnV"), only those areas
to which the user is the File-Op are listed. If the sysop is
not the File-Op of an area, he too will not see (not be
bothered with)its unvalidated files.
When entering descriptions for files, only the File-Op can
avoid description censoring.
When using the following commands, the File-Op will only be
allowed at files that are in areas under his control:
command title menu command
Oust Files RemF
Oust Files/Penalty UPen
Validate Files ValF
File Maintenance File
Normally, to support a File-Op you will have to create a
File-Op menu for him to use. The above commands are a good
start.
This menu would normally contain at least Oust Files and File
Maintenance. Also "convienence" commands such as: Add File
Review, Leave a Private Message, Feedback to Sysop, List Your
Area (a "PagF _#" command), etc.
You will probably also have to "ghost" the File-Op a higher
Security Level. If they are SL 10, give them SL 11. Then in
your SL's configuration, add SL 11 but give it a "show" value
of 10. That way you can make a command to let them go to
their File-Op menu without other level 10 users accessing it,
and you still limit this File-Op to normal (say, not level
20) commands (because everything below level 20 is not level
20). By using a "show" of 10, he doesn't know he's level 11.
Or you could save yourself the ghosting hassle and just give
them a higher SL.
-87-
FILE AREAS File Area Definitions (File Area Maintenance)--like all
configuration stuff--is done in the sysop menu.
EXCLUDE.LST can which can be used to stop the creation of
files matching specific filenames. Useful with CD-ROM's that
have multiple files (such as FILES.BBS) in each directory.
Defining File Areas consist of the following fields:
Download SL (minimum and maximum)
Only when a user has an SL that is at least that of the
minimum, and no more than that of the maximum, will they be
able to download files from that area.
Example: if you use 5 for min, and 10 for max:
SL < 4 cannot DL
SL 4 cannot DL
SL 5 can DL
SL 6 to 9 can DL
SL 10 can DL
SL 11 cannot DL
SL > 11 cannot DL
Normally, you just set the SL to something high, like
32000. But this "windowed access" capability lets you
restrict access to users of even high SL from certain
areas.
Upload SL (minimum and maximum)
Only when a user has an SL that is at least that of the
minimum, and no more than that of the maximum, will they be
able to upload files to that area.
For this to matter, you must also set File Area Attribute 4
(allow uploads) ON.
Scan/List SL (minimum and maximum)
Only when a user has an SL that is at least that of the
minimum, and no more than that of the maximum, will they be
able to list (scan/view) the contents of that area.
This is also the access limitor SL. So users outside this
SL range cannot switch to this area. Nor will they see it
listed on any internally generated selection menus.
-88-
These SL values are also what is used to form Master List
"SL tiers". We create a Master List for each tier of
access SL's (vs. normal SL's).
Example: File Area 1 SL = 0
File Area 2 SL = 10
File Area 3 SL = 20
Gives us 3 SL tiers: < 10, < 20, 20+ for which we will make
3 Master Lists. When a user downloads the Master List,
they are given the list appropriate for their SL.
Access Time (start and end)
A user may download, list, or upload files to this area
only during the defined hours. Note that, starting an
upload or download inside the valid time, that then extends
outside the allowed time (eg. downloading a massive file)
will be allowed.
Set these to be the same (such as 00:00:00) to allow 24
hour (continuous) access.
When outside this time, the File Area will not be
accessible, and users will not be allowed to select files
from that area. It will be as if the File Area did not
exist.
Circular buffer size.
If this field contains anything other than zero, than the
File Area is said to have a "circular buffer". Whenever
the number of files in that area reaches this value, the
oldest file will be deleted. Example: if you set it to 50:
if there are 50 files in it, and someone uploads 3 files to
this area, then the oldest 3 files will be deleted. So
there will be 50 files again. If there were 45 files, then
it would have 48 files--since it did not reach 50, there
was no need to delete files. A zero value in this field
means there are no limits on the number of files that can
be active in this area.
Oldest file being the one in the area/on the BBS the
longest--not by current file date. The "never auto-delete"
file Attribute will let an old file escape deletion.
[note: the circular buffer is really not working]
Attributes
2 means that you wish uploads and downloads to/from this
area to show up in the Callers Login such a way that all
users can see it. If OFF, only the sysop will see the
transfer information.
-89-
3 means that you wish the L&D/Point values to be shown
when listing the contents of the area. Setting this OFF
overrides the user's toggle to view the L&D/Point
values.
Whether the L&D/File Point values are visible may also
depend on which Form Type you use.
4 means that users may upload to this area. When not
included, any uploads attempted to this area go to area
number 001 (if possible).
5 Normally files are listed in alphabetical order (A to
Z). When this is ON, files will be listed in order from
newest to oldest.
6 means that files in this area are said to be
"transient". This is for such as floppy or CD-ROM
drives--where you swap in and out disks of files
frequently. When this is ON, auto-deletion of file
entries not found is turned off.
Example: You have two floppies, each with two files.
With this OFF, each time you exchanged floppies the
system would automatically delete the file entries of
the files on the out floppy. With this ON, you can swap
the floppies without having to redo the descriptions
each time you swap in a new disk (although you do have
to do them the first time, like any new file).
For multiple CD's in the same drive, they must have
different directory structures (defined File Areas) and
by keeping both with this ON, you'll be able to rotate
the disks.
When this is ON, the contents of this area will not be
put in any Master List either.
It is only useful for BBS's which like to have a
rotating file collection: "specialized CD each day of
the week" type of system.
Simply giving a File Area(s) an List/View min SL of
32000 might, in some cases, be better than using this
Attribute. You give the SL on the "out" CD's, and
change it to normal for the "in" CD. See the sysop
command to globally change File Area SL values.
7 Normally the directory is sorted before displaying.
Turning this ON tells you to list it as it is. This
does not matter if 5 is ON.
-90-
Mainly useful for CD areas which have already-sorted
directories. However, the ability to fold directories
into each other, and to ghost files into other
directories, is making this Attribute increasingly less
useful.
9 means you do not wish the software to do auto-
corrections of the entries in this area while displaying
the contents of this area. These auto-corrections
include updating/fixing file sizes, file dates, File
Area information. As well as discovering new files and
removing entries for missing files.
For CD-ROM directories, this should be ON once you get
the area and its descriptions/etc. set up the way you
want it. It speeds things up, particularly on areas
with lots of files.
However, if you have a Primary Path defined on a hard
disk, and fold in multiple CD areas, you may still want
to leave this OFF so the auto-fixing is done on the hard
disk area. Although, certainly, any all-CD areas should
have this ON to speed things up.
With large numbers of files in an area, or areas with
lots of EXCLUDE.LST files, can be speeded up by keeping
this Attribute OFF. But if you do turn if off, remember
that the software will not auto-discover and auto-remove
entries when you copy/delete files in that directory
from DOS. Although the Oust Files and Move Files
commands will manage the directory properly.
A means to not include the contents of this area in any of
the Master Lists. Master Lists are created individually
for each user SL tier. Useful if you keep the
descriptions in a user-downloadable list of your own
(such as a ready-made list of your CD areas--speeds up
building of the Master List by being able to skip some
areas).
B means that all files in this area are to be free.
You may mix-and-match the above attributes.
Maximum MB
This defines the maximum number of megabytes this area may
be. When it gets near this value, users will not be able
to upload to this area. Beyond upload restrictions, this
value is not used.
-91-
When uploading to this area, the "amount of free space"
shown is not the real value, but rather this maximum less
what is already used up. Example: if this is 100 (100 MB),
and 96 MB are used, it will show "4 MB free" (unless there
is less than that really, then it will show the real
amount).
[note: the Max MB limitor is really not working]
File Form
This defines which file listing format/type we should use
when displaying this area.
Sample formats are in the HELP\TYPES directory. The actual
definitions are stored in GLOBAL\TEXT\LISTING.TXT (see the
file for additional information). You may use one of the
predefined types, or create your own. It is an EXTREMELY
flexible system, allowing you to change everything about
the headers and the way the file lines are to be displayed.
NewFilesPtr
This is the value of the highest NewFilesPtr that this File
Area has ever seen.
This is maintained internally, so you normally would not
mess with it. However, it should also be reasonable
(usually under 100,000). If it becomes unreasonable, just
set it to 0 and it will fix itself. Sometimes a corrupt
FILELIST.HDR file can mess these values up.
File-Op
This is a name field, and contains the name of the
"overseer" of that file area.
You, the sysop can do many file functions, including
delete, modifying the descriptions, etc. Including a name
here will allow that user to ALSO do these functions (only
one name allowed).
Only those with "sysop" Security Levels, or the name in
this File-Op field will be able to "work on" files in this
File Area. Useful for delegating the maintenance of a file
area to a user.
It is usually very helpful to File-Op's to create a menu
containing commands they may use. Such as File
Maintenance, List Unvalidated Files, Validate Files, etc.
All of these have special restrictions which will only give
the File-Op access to files in his controlling areas.
-92-
Primary Path
This contains the primary path to which this file area
refers.
When a user uploads a file to this area, it goes in this
directory.
When the sysop moves a file from one File Area to another,
the file is moved into this directory. Note: ghosting
files to other File Areas does not move them.
Title
Refers to what the users see as the title when they list
the contents of this File Area.
Additional Paths
Finally, the good stuff.
These fields let you define up to 6 directories which you
may "fold" into this File Area.
"Fold" means that when this area is listed, it lists all
the files in the Primary Path, and these additional paths.
The files are also sorted into alphabetical order. To the
user, it will look and act just like a single directory.
We do not write or store any files to these additional
paths. And they need not be only directories. For example:
D:\WIN_3 will use all files in the WIN_3 dir, but
D:\WIN_3\W*.ARJ can also be used to only include those
files from that dir that start with "W" and have the ".ARJ"
extension.
Best used for folding multiple CD areas into a single area.
But you can specify hard disk directories as well.
Commonly used to merge CD areas with a hard drive area:
Primary Path: C:\WIN
Additional Path: D:\WIN_2
Additional Path: D:\WIN_3
Thus, all your Windows files are in an uploadable Windows
directory, even though most of them are on the CD.
Be careful though. The software is not designed to handle
more than 1000 files per area, so when you are folding
dirs, try to keep below this limit (think of the poor user
who will page through all those files).
You can use /RESCAN and /RESCANALL to do auto-fixing if you
have a lot of fixing to do. Both compare what is on your
-93-
disks with what is defined as being on the BBS. Then it
cleans things up. Only "file is on-line or not" problems.
That is, if you dump a a bunch of new files into an area--it
would find them and create entries. If you deleted a bunch
of files, it would delete their entries.
What it won't do is match the files with an area. Example:
if you exit to DOS, copy a file from area #1 to area #3,
doing a /RESCANALL will not fix the area. That's done when
you list the area with Attribute 9 OFF. If area #3 has
Attribute 9 ON, then its going to stay invisible until you
turn it OFF.
/RESCANALL goes a step farther and also checks the CD
(Attribute 9 ON) areas that /RESCAN normally skips. Usually
if your file system seems so messed up that you're banging
your head--and your File Areas look fine, then doing a
JDRBBS.EXE /RESCANALL will cure it.
Upload-stopping works as follows:
If the current area does not have Attribute 4, or the SL
for the area is too high for the user, then we change to
area 001.
Then the same checks are made, if the user does not pass
them all, then they are not allowed to upload.
Some sysops like to make area 001 a hidden area, and force
all uploads to it. Then at some later time the sysop looks
over the files in area 001, and moves them, tests them, or
whatever.
Menus The software will provide you flexibility to access your File
Areas with whatever method you want. These include:
an internally (quick) generated menu, ANSI menu, and
complete systems.
Internally (quick) generated menus:
These involve making use of the "_g##" and "_all" some
commands have. "SelF _all", for example, will give you a
menu of all File Areas you can access. "SelF _g##" will
produce a menu of those File Areas you defined to be in
that group (see File Area Group Handler), and to which you
have access.
After the menu, the "SelF" command merely switches to that
file area. Other commands are "PagF" and "Upld". All work
similarly with the "_all" and "_g##" by first bringing up a
menu and then listing the contents of the selected area, or
uploading to that area, respectively.
-94-
ANSI menus:
This involves putting individual commands into an ANSI.
Once again, the commands are: "SelF", "PagF", and "Upld".
However, instead of using the "_g##" or "_all" extensions.
You use these commands with no extensions (except "SelF")
or with the "_#" extension (where "#" is a File Area
number, eg. _1 for File Area #1).
You create commands, and put the commands onto menus.
Example: to list File Area #20: "Ls20" = "PagF _20". Then
anywhere you put "Ls20" it will list/access File Area #20.
Additional commands of use are: "PrvF" and "NxtF", for
"goto previous File Area", and "goto next File Area",
respectively.
Complete systems:
These are extended listing systems. They include "PagQ",
"PagA", and "P&Sx".
"PagQ" will ask you what you want to do. Selecting "All" is
equivalent to a "PagA".
"PagA" will cycle though all the file areas accessible
using the paged method.
"P&Sx" is the Point & Shoot system.
A common factor to all the systems is the batch download
queue. It is accessed via commands when listing the area,
and automatically with the P&S system. And you can use "CntB"
and "AddB" for ANSI menu options.
By having this wide variety of commands, you may put File
Areas any where you want. You could, for instance, shove
them into a bunch, or break them up by topic--each having its
own message area, menu, etc.
Remember, however, that while the ANSI method provides you
the maximum possible control of menu selection; the more
general commands are easier to start with.
The commands can be thought of as differing ways of doing the
same thing. For instance, "PagQ" is one menu command, but
requires two key strokes to do something. You could do the
same with 4 menu commands ("PagA", "PagN", "PagF _all", and
"PagS") requiring only one keystroke. Same thing, different
philosophies for different sysops.
-95-
See also: MENU COMMANDS: File
Diagrammed The file system can be thought of as being two separate
File Examples parts: the first part selects a file area, the second part
lists the contents of that File Area.
The reason they are two parts is because once you select a
File Area to list, you can move to other File Areas without
having to return to that first selection menu.
The file system offers a plethora of possibilities: with the
menu commands, you can have the software list all areas at
once, provide a menu of all the areas, use your own menu of
all or some areas, provide a menu of some areas. You may put
some or all your file areas into a single file system, or
bust them all up so they are grouped together or individually
(known as topical menus: putting a related message area(s)
and related file area(s) into the same menu).
All of the commands below exit back to the menu when
completed. You can put a "DReq" or somesuch after them to do
another command before they return to the menu.
"PagQ" menu command:
"PagQ" is the most powerful of all the file commands. A
sort-of "all-in-one" command. Most of the other commands
are made up of some fragment of this command. What this
command does is first ask the user what they want to do:
access all files, access files matching a search string,
access all new files, or select a File Area to jump to.
With access-all-files and select-File-Area, once the user
is in the file system they can move to any directory. But
matching and new-files does not offer such flexibility--
limiting the lists to files containing a string, and new
files, respectively.
"PagA" menu command:
┌────────────────┐
┌────────┴───────┐ AREA n │
┌────────┴───────┐EA 001 │ze desc │
│ FILE AREA 001 │ze desc │ze desc │
│ file size desc │ze desc │ │
│ file size desc │ ├────────┘3
│ Option: ├────────┘2
└────────────────┘1
Each file area is gone through. At every 18 file names or
so (depends on screen size) at the end of a file area, a
prompt is displayed. At this prompt the user has a wide
selection of commands including commands to move to any
area number. This works just like the "PagQ" access-all-
files option.
-96-
"SelF _g##" menu command:
┌────────────────┐
│ SELECT AREA: │
│ A) area 001 │
│ B) *area 005 │
│ C) area x │
└────────────────┘1
A menu is presented containing certain File Areas (defined
as a group in Group Handler). When they select an area,
they are exited from this areas menu back to the calling
menu--we do not list the area. Only areas to which the
user has access are shown in the selection menu.
"SelF" menu command:
┌────────────────┐
│ SELECT AREA: │
│ A) *area 001 │
│ B) area 002 │
│ C) area n │
└────────────────┘1
A menu is presented containing all the accessible File
Areas. When they select an area, they are exited to the
menu. This is just a "switch to File Area" command, not a
"switch and list" command.
This command is exactly what you would get using "SelF
_g##" if the defined group contained all file areas.
"PagF _#" menu command:
┌────────────────┐
┌────────┴───────┐ AREA n │
┌────────┴───────┐EA 007 │ze desc │
│ FILE AREA 006 │ze desc │ze desc │
│ file size desc │ze desc │ │
│ file size desc │ ├────────┘3
│ Option: ├────────┘2
└────────────────┘1
This command jumps to File Area "#" and starts listing
files in that area. One may then choose to move to other
areas. These "PagF _#" commands are good for using your own
ANSI as a File Area selection screen rather than the
internally created one.
"PagF _g##" menu command:
┌────────────────┐
┌────────┴───────┐EA x │
┌────────┴───────┐EA 005 │ze desc │
│ SELECT AREA: │ze desc │ze desc │
│ A) area 001 │ze desc │ze desc │
│ B) *area 005 │ze desc ├────────┘3
│ C) area x ├────────┘2
└────────────────┘1
-97-
A menu is presented containing certain File Areas (defined
as a group in Group Handler). When they select an area,
they are given the contents of the area. They then can
move to other areas. When they exit, they are exited back
to the original calling menu. Only areas to which the user
has access are shown in the selection menu.
"PagF _all" menu command:
┌────────────────┐
┌────────┴───────┐EA 003 │
┌────────┴───────┐EA 002 │ze desc │
│ SELECT AREA: │ze desc │ze desc │
│ A) area 001 │ze desc │ze desc │
│ B) *area 002 │ze desc ├────────┘3
│ C) area n ├────────┘2
└────────────────┘1
A menu is presented containing all the file areas. When
they select an area, they are given the contents listing of
that area, they then can move around and list other areas.
When they exit, they are exited back to the calling menu
(not this areas menu). Only areas to which the user has
access are shown in the selection menu. This is the same
as "PagQ"s select-File-Area option.
This command is exactly what you would get using "PagF
_g##" if the defined group contained all file areas.
"P&Sx" menu command:
┌────────────────┐
┌────────┴───────┐EA 001 │
┌────────┴───────┐ AREA n │le file │
┌────────┴───────┐EA 002 │le file │le file │
│ FILE AREA 001 │le file │le file │le file │
│ file file file │le file │le file ├────────┘1
│ file file file │le file ├────────┘3
│ file file file ├────────┘2
└────────────────┘1
The user has a wide selection of commands while at the P&S
display. You can move both forward and backward through
the File Areas. Only those file areas to which they have
access do they see.
There are other interesting file commands available too.
Files In Area When you copy files into a File Area, these files are
"outside the BBSs domain". That is, the software does not
yet know about them. So, some functions, that require an
active file's filename will not yet "see" the file.
However, as soon as they are "seen"--when you or a user lists
the files in a File Area--then they are "discovered" and
given an entry, making them active.
-98-
When the software discovers files, the files are assumed to
be complete (vs. a partial upload), and just given a blank
description (shows up as "?").
CD-ROM's CD-ROM's (and other optical disks) come with lots of files
and lots of variety. Some have lots of directories with few
files per directory, others have a single (or a few) large
directories only. Either a few very large directories or a
reasonable number of medium sized directories is best. Those
disks that use numbers for file names, that don't compress
their files, or that put just a couple files per directory
(and have hundreds of directories) I recommend you stay away
from.
There are two ways of accessing CD files with this software.
Using a door program, or defining the CD's directories as
normal file areas (as if they were on your hard disk).
Uncompressed directories, hundreds of directories, or
numbered filenames--then you've not much choice, use a door
program (better yet, through the CD out). Otherwise I
recommend defining the file areas. Since it provides the
same seamless file access as normal File Areas.
To avoid having all the CD-ROM files be considered "new" to
new users, you can set #NEWUSER's NewFilesPtr to 1, and that
of all the CD-ROM directories to 0.
Also review the sections above on File Area Attributes and
Additional Paths.
Special Cases Normally, you provide access to your File Areas on a "the
higher the SL, the more File Areas you can access" method:
File Area #1 Access SL = 0 to 32000
File Area #2 Access SL = 0 to 32000
File Area #3 Access SL = 0 to 32000
File Area #4 Access SL = 10 to 32000
File Area #5 Access SL = 20 to 32000
Thus, SL 20+ can access all areas, SL's 10 to 19 can access
only areas 1 to 4, and SL's less than 10 can only access
areas 1 to 3.
Well, that maximum SL is looking pretty useless, isn't it?
And normally it is useless, because rarely do you want to
deny files to people when possible.
But lets give the File Areas above some descriptions:
File Area #1: GIFs of cars
File Area #2: GIFs of planes
File Area #3: GIFs of movie stars
-99-
File Area #4: Tiny Toon GIFs
File Area #5: Beastiality GIFs
You want to make area #4 and area #5 accessible only to paid
users. And you want to tailor it so users who get area #4 do
not get area #5, and users who get area #5 do not get area
#4.
First: note that this is extremely rare in the real world,
and if you are thinking about this, chances are you are
thinking too hard about your File Area setup.
File Area #1 Access SL = 0 to 9
File Area #2 Access SL = 0 to 9
File Area #3 Access SL = 0 to 9
File Area #4 Access SL = 10 to 19
File Area #5 Access SL = 20 to 32000
This won't do it! It gives regular users access to areas 1
to 3, and separates the area 4 and area 5 users. But what we
want is to also let those area 4 and 5 users access areas 1
to 3.
Note: the sysop can access all areas no matter what the
security level restrictions are.
In fact, no combination of SL's will let us do what we want.
To get what we want, we have to change the order of the File
Areas:
File Area #1: Tiny Toon GIFs
File Area #2: GIFs of cars
File Area #3: GIFs of planes
File Area #4: GIFs of movie stars
File Area #5: Beastiality GIFs
And set the access SL's as so:
File Area #1 Access SL = 1 to 4
File Area #2 Access SL = 0 to 32000
File Area #3 Access SL = 0 to 32000
File Area #4 Access SL = 0 to 32000
File Area #5 Access SL = 6 to 32000
Thus, new users of SL 0 (or 5) can only access areas 2 to 4.
But if a user pays, and wants the Tiny Toon dir, you give
them SL 1 to 4 and they will be able to access that dir along
with 2 to 4. If a paid user wants the Beastiality area, you
give them SL 6 or higher, and they will be able to access
area 5, and areas 2 to 4.
-100-
You didn't really need to re-order them, but it makes this
example clearer. Showing that location of File Area doesn't
matter, and that the SL fields of File Areas before and after
do not matter. A user is allowed access to a File Area only
if their SL is in that File Area's range.
But more important than this example is to remember how "SL
Ghosting" works--in which internally a user may have one SL,
but the SL they see as theirs (the Show SL) can be something
different. This is very useful, for example, when you want
to give a fellow sysop higher SL, but don't want them
accessing any private File Areas. Just "Show" them a higher
SL, and they'll never know the difference.
Ghosting files You can now "ghost files". Ghosting is showing the user one
thing, when it's really something else. In this case, we
show the user a file as being in one File Area, when it's
really stored in another File Area. To accomplish this,
merely edit the files' record so that "Show Area" contains
the area to-which you wish to make the file appear. Useful,
for example, for "moving" files out of one CD area and into
another (such as when a Graphics dir program was wrongly
placed in the Text Files dir, etc.).
The file will act just like a file in that Show area. It
will be displayed with that area's contents listings, it will
be limited by that area's Attributes and SL's.
Note: you cannot ghost files from one "non-CD" (File Area
Attribute 9 OFF) area to another "non-CD" area. One or both
of the areas (the real area containing the file and the
ghost/sbow area) must be a "CD" area. You could, for
example, put all your .GIF's into one area and ghost them by
type into multiple areas (set Attribute 9 ON for either the
one area, or the multiple areas, or both).
-101-
MESSAGE AREAS Message Area Defintions (Message Area Maintenance)--like all
configuration stuff--is done in the sysop menu.
Defining Message Areas consist of the following fields:
Post SL
This is the Minimum Security Level value a user must have
to be able to leave a message in this area.
Read SL
This is the Minimum SL value a user must have to be able to
read messages in this area.
Scan SL
This is the Minimum SL value a user must have to scan/list
messages in this area.
This is also the access limitor SL. So users with less
than this SL value cannot switch to this area. Nor will
they see it listed on any internally generated selection
menus.
Access Time (start and end)
These define a time window which the Message Area may be
accessible. This is rarely used.
Set the start and end times to the same thing for 24 hour
(continuous) access allowed.
Max Messages
If this value is not 0, then we delete the oldest messages
in this area when the total number of messages in this area
reaches this value.
Example: set this to 500, then once we reach 500, each time
a new message is added, the oldest message in the area is
deleted. Thus keeping the total number of messages in this
area at 500. Very useful for popular Echos.
You can protect messages from deletion by setting their
"don't auto-delete" Attribute.
Set this to 0 to disable automatic deleting.
Next Number
This is an internally used field, and is unlikely to be
modified by you.
-102-
It contains the number to give the next message posted in
this area.
If you see that the number is really screwed up (8 digits
for example) then you should fix it to something
reasonable.
Attributes
1 means that the FROM: field should be forced to
"Anonymous" for all messages posted in this area.
Nobody (but the sender) will know who left the message.
2 means that this is a Private area. The messages are
only visible to the sender, receiver, or Message-Op.
When OFF, the area is Public, and the messages are
visible to all.
When using the various message reading menu commands,
pay attention to which read private mail, and which read
public mail. They do not necessarily read each other's
type.
3 means that the area should be inspected when receiving
or sending Net Mail packets. It is also necessary if
you wish to enter a node address when entering mail, and
seeing the node addresses when reading mail. If an area
does not have this Attribute, then no Net Mail will be
put there, and no messages will be sent out from there.
Also, this Attribute tells the software to add special
"^A" "kludge" lines to the message.
You can really have only two areas with only Attribute 3
ON (and not with Attribute 9 ON): private NetMail, and
public NetMail. With private NetMail, any private Net
Mail that does not have a matching EchoMail message area
will be put here. Similarly for public NetMail. If you
have only one NetMail area, then both private and public
NetMail goes there. No net areas? Then inbound NetMail
(and no-area EchoMail) will be put into the Private Mail
area.
5 means that only the Message-Op can delete any messages
in the area. This stops both the poster and receiver
from deleting the message. Useful for areas which
provide information that others might be interested in.
6 means that all messages are forced to use "ALL" as their
"TO:" field. This includes replies. Nobody is allowed
to enter a name in the "TO:" field.
-103-
7 means that NetMail "kludge" lines are shown (these lines
begin with an ASCII 1--a little happy face). This also
toggles the showing of EchoMail lines: ---, * ORIGIN:,
SEEN-BY, and AREA:.
The Message-Op can hit "S" when reading messages to
toggle this ON and OFF on-the-fly.
8 means to automatically delete NetMail messages in this
area after they are [Sent]. Obviously, this also
requires Attribute 3 to be ON. Normally this should be
ON for your NetMail areas (but not EchoMail).
9 means the area is an EchoMail area. Attribute 3 must
also be set to ON for any EchoMail area. Thus, when
this Attribute is ON, so must be Attribute 3.
A means we should append the BBS's own Origin lines to
outbound EchoMail messages from your BBS. The Origin
line is usually just wasteful garbage, and if you want
to attach one, see SHORT.TXT.
B means to use the author's real name for the FROM: field.
This is used to "force" real names--some EchoMail areas
demand it.
C means to NOT include the sender's name in the quoted
brackets.
Example: ┌(John Rohner) ┐ becomes: ┌ ┐
│text │ │text │
└ ┘ └ ┘
D means to report the active status of the sender and
receiver names. If the name is not in the current users
list, they have a little "(not a current user)" noted
beside their name.
This is particularly useful for Private Mail.
E means to allow anything in the At: field. Normally
long-form addresses like for Internet.
We do not really use this now, but it will be in the
future.
You may mix-and-match the above attributes.
Message-Op
The Message-Op is the sysop of the Message Area. Any
messages posted TO:SYSOP in this area will get that persons
name.
-104-
Beyond that, there isn't much special about a Message-Op.
They can look at any message, delete any message, etc. But
a lot of their power relies on what the sysop gives them.
Some nice things the sysop can give them is the ability
lock/unlock access to one or all users to the message area.
See the "Lock", "LsLk", and "UnLk" menu commands.
The sysop could outfit a Message-Op menu with related
commands, maybe a related file area, etc.
Title
The title of a Message Area is what is displayed when
scanning the area, reading messages in the area, and for
internally generated select-area menus.
You are free to modify any areas as you wish, except for area
#1. This is always Private Mail. The Message-Op is always
the sysop.
Menus The Message Area commands are quite similar to the File Area
commands. For instance, "SelM" to select a Message Area is
just like its "SelF" (select File Area) brother.
Most of the other commands, for reading and writing messages,
are less generalized and usually only offer the non-parameter
form (uses the current area) and the "_#" parameter form
(switch to area "#" first and then do the command).
Toggling When a user toggles a message area INACTIVE, it is quite
similar to making the area out of their SL range.
All menu commands that build menus of Message Areas to switch
to will not display those that are disabled.
The next/previous area commands will similarly jump over
these areas.
Only 3 things work: the Message Area toggle menu will show
them, login mail read will allow the user to read messages in
these areas, and the "SelM _#" command also works (eg. "SelM
_3"). This list of can-do stuff is the same for SL-
restricted message areas.
This "disappearing" is done because that is assumed to be the
way the user wanted it when they chose to toggle inactive the
areas. Out of sight, and out of mind.
-105-
PSEUDO-AI The Pseudo-AI can only send private messages (E-Mail) in and
out of the Private Mail base, number 001.
Any messages redirected from the AI to the sysop go to the
sysop.
All software generated messages (such as AI's "Hello", or
Return Receipts) have their "kill when received" Attribute
ON. This means that when the message is read, it will
automatically be deleted. That is, the AI automatically
cleans up after itself (a lot of users don't delete their
mail). But the messages the AI sends are every bit real and
normal.
Beyond messages, however, the Pseudo-AI is the "smarts" in
the program. When a user doesn't have to do something that
he normally would do, the AI is said to have done it for him.
-106-
MINUTES There are 3 types of time maintenance minutes. There are
Access Minutes, Download Minutes, and uploading.
Uploading is easy to understand: no time is reduced from
anywhere during uploading, and they may even get Download
Minutes if you have auto-crediting for the uploads ON.
Download minutes are just that: minutes a user is allowed to
spend time downloading. This is reset each day to the values
specified for their security level. This value is also used
to determine the maximum amount of time a user may spend in a
door per day. For that reason, they may be referred to as
Download/Door minutes.
Access Minutes are everything else: putzing about on the BBS,
reading messages, etc. The kind of thing you usually want to
give users a lot of. There are per-call and per-day values
for this. Uploading/downloading and dooring do not count
against these values.
With high speed modems, download minutes don't really matter,
and tend to act as merely door-access-limiting minutes.
Download/Door minutes get used up when downloading or in
doors. But first the "free" minutes you give them each day
is used, then when they have exceeded those we start
subtracting (permanently) any "given" minute credits they
had.
When a user's minute-credits reach or exceed 32,767, it will
never increase. When it reaches -32,767 it will not be
reduced farther.
Crediting of download minutes for uploads is defined in the
protocol definitions, and in Settings: Extended File
Crediting (for those who like exotic crediting schemes).
-107-
GROUPS There are lots of groups with this software. Groups are
good.
The is grouping by security level. You know all about this.
Another is groups of users based on their name. You do this
in the sysop menu option: Users: Group Handler. With these
groups, you are able to restrict access to both files and
menu commands (the "ifGP"/"ifnG" commands).
The last user grouping is Linkages, and is the least used.
Linkages allow multiple users to maintain common file
transfer statistics. So that when one uploads, the other guy
can make use of those credits for downloading. This is done
in the sysop menu option: Linkages, and is otherwise
invisible. It takes effect when downloading--as the users
statistics will appear different than if he were not linked
with another user.
A single name can be put into a group. This allows you to do
such things as limit a file, or whole command operations, to
a single person. The IndividualANSIs system is particularly
for single-user stuff as well.
The other types of groups are groups of Message Areas, File
Areas, and Doors. These work like the user Group Handler
system, and have their own group management commands.
-108-
VOTING The voting questions are contained in the VOTE.TXT. This
file is structured as follows:
Number: total number of questions
Text: line 1 ┐
Text: to line n: question text │ a
Number: total number of options (x) │ single
Text: line 1 │ question
Text: to line x: options text ┘
Text: line 1 ┐
Text: to line n: question text │ a
Number: total number of options (x) │ single
Text: line 1 │ question
Text: to line x: options text ┘
Text: line 1 ┐
Text: to line n: question text │ ...
etc.
Or to simplify:
n <- Total number of questions.
Text Q1 Line1 <- Question 1, can be up to 14 lines.
Text Q1 Line2
3 <- Number of options for question 1.
Option1 <- Each option. Can have up to 7.
Option2
Option3
Text Q2 Line1 <- Question 3, can be up to 14 lines.
Text Q2 Line2
4 <- Number of options for question 3.
Option1 <- Each option. Can have up to 7.
Option2
Option3
Option4
Text Q3 Line1 <- Question 3 on, same as before.
etc.
Example:
2 <-number of questions.
Do you like furry animals? <-question #1
3 <-number of options.
Yes <-option 1/3
No <-option 2/3
Yes when they are in a zoo. <-option 3/3
Do you like the great outdoors? <-question #2
4 <-number of options.
Yes, I visit them a lot. <-option 1/4
Yes, I have a garden. <-option 2/4
Yes, I have a plant at the office. <-option 3/4
No, burn it down. <-option 4/4
-109-
You may only have a maximum of 7 of your own options for a
user to select from. But the software also provides an
"No Opinion" and "Other" (the default) options for each
question. Giving you up to 9 possible answers.
The "No Opinion" option is the same as not voting--and will
result in the question repeatedly coming up (next call) if
the voting is is being done at login (mandatory/forced
voting). "No Opinion" is not considered a real vote, and so
is not graphed.
When a user chooses "other" (the final voting question
option), they are prompted to enter text describing what they
mean. This can sometimes be a simple option you neglected to
include, or a whole complex belief idea. this text is then
sent to the sysop as a message from the AI. You may then use
their answer to decide if the voting options need more
options.
When an option's text runs into the graph, you will need to
shorten the option's text.
The graph shows all options except "No Opinion".
The graph automatically re-size's itself between 50% and
100%--to maximize graphic variability.
Deleting a voting question is a bit tricky. You cannot
simply delete a question unless it is the very last one.
This is because if you did simply delete it, all the others
would move up one--and all the user records (where the
results are stored) would have results for the wrong
question.
So when you want to delete a question, you should first come
up with a question to replace it with (and change VOTING.TXT
with this new question). Then go to the sysop menu and
select "Reset Voting Question", and then "Update Stats"
("Update Stats" will reset that voting question's totals to
zero).
-110-
DOORS A door program is any program you temporarily pass control
too. The key word is "control". Simply shelling and running
programs like DSZ.EXE or PKZIP.EXE is not dooring to those
programs.
Defining Use "Door Maintenance" from the sysop menu to maintain doors.
This is a defining database, it has nothing to do with the
menu commands. It creates "door objects" which the door menu
commands can use to actually execute doors.
The whole door system works very similarly to the File Area
and Message Area systems. The menu commands work are quite
alike.
Doors consist of the following fields:
Access Time (start and end)
Access to this door is allowed between, and including, the
times supplied here. If the two values are equal, then
access to the door is allowed during all 24 hours.
When using the "DOOR" and "DOOR _g##" commands, if the door
is inaccessible at that time, it is not included on the
menus.
Maximum time allowed in door
The maximum number of minutes a user is allowed in the door
per door access. The door handles this, so it is by no
means guaranteed. Use some high number (like 999) for
unlimited access time.
If the user's "download minutes" is less than this amount,
then their "download minutes" amount is used instead. That
is why they are called Download/Door minutes.
A zero value will still execute the door (it is always the
door's responsibility to guard the time) but if it is
handled properly by the door program, they will not be able
to use the door program.
You'll learn quickly to hate doors that have no time-
limiting code.
Logging type
0 = none
9 = everything the door program has
1 to 8 are somewhere in between (door program defines, you
should look at the door program's documentation to see if
it supports this capability).
-111-
Minimum drive space needed
The minimum drive space (in bytes) that the door needs on
the drive to run. Usually this will be very small. If you
want to use 0, you should be sure the door program updates
no files (including the door-exit files). 2048 will be
fine for most doors, but some may need a lot more if they
need to update large data files (example, a daily packing
would need at least a megabyte--probably 2 or 3). So it
varies widely, which is why this field is here--the door
program will not be run if there is not at least this
amount of drive space.
Door-Op
Who is to be the door-sysop for this door. Only this name
will get sysop treatment from the door program.
Path
Drive\path specification of the door program. Example:
C:\BBS\DOORS\BRE or C:\BBS\DOORS\BRE\ or E:\ etc. It
should contain the path of the door programs' files. Where
the door is on your hard disk.
This field is the drive that is checked to determine that
there is enough space. If empty, no space checking is
done.
This field is almost never empty.
Execution
Filename and command line to execute the door. If your
door program is at C:\BBS\DOORS\ABC.EXE you would put
C:\BBS\DOORS\ above and ABC.EXE here.
Command lines are of the form:
ABC.EXE %N %D\ABC.CFG /a /k
Where you are mixing the doors' "%" commands with whatever
command line commands the door program wants.
The following "%" codes are expanded when found in the
execution line:
%P Comm port (1..n) being used.
%N Node (1..n) being used.
%B Baud rate (2400, 4800, 9600, 14400, 19200, 38400) of
user (actually it's of your computer<->modem
connection, but it is what door programs want).
-112-
%D Path to current door's directory (what you specified
in Path above). No trailing slash is added.
%T Max minutes (1..n) allowed in door.
%W User's name (spaces converted to "_").
%X User's name (spaces kept intact).
Example: ABC.EXE /NODE=%N /CFG=ABC.CFG
Note: "%P%P%P" expands to "111" but "%P %P %P" is "1 1 1"
(if comm port = 1 of course). That is, no leading or
trailing spaces are added when substituting for these
codes.
Most doors will accept a filename in the command line to
mean a file in the current directory (the directory in
which the door program resides). So it is rare that you
will ever need %D or any path in the command line.
These codes are the same as used by protocol execution
lines. The door program will decide which ones you will
need to use.
Title
The title is displayed for any internally generated
selection menus.
Exit Info Attributes
These are used to tell the software what type of door exit
file the door wants, and whether we should do a full exit
from the BBS or not.
The vast majority of door programs assume a BBS is just a
dumb front end. And they go into great detail about batch
files to run their programs, and configuration setups, etc.
Ignore it all! Never, ever, give a door program any path
other than that of its own directory (eg. BBS\DOORS\ABC).
The only exception to this rule to maybe give it the
location of your Callers Log so it can log some sysop info
for you (rare).
This software is smart. It not only exits itself into that
door programs directory, but also puts the door-exit
file(s) in that directory as well. The directory we do
this with is whatever you put in the Path field above.
The following are the Door Exit Attributes:
1 This produces a DORINFOx.DEF door-exit file. Also known
as "RBBS" type door-exit file. Almost all your doors
-113-
will use this. Only the older door programs may need
something else.
2 This produces a DOOR.SYS door-exit file. Also known as
"Gap" type door-exit file.
3 This produces a CHAIN.TXT door-exit file. Also known as
"WWIV" type door-exit file.
4 This produces a SFDOORS.DAT door-exit file. Also known
as "SpitFire" type door-exit file.
5 This produces a PCBOARD.SYS door-exit file. Also known
as "PC-Board 14.x" type file.
6 This produces a PCBOARD.SYS door-exit file. Also known
as "PC-Board 12.x" type file.
7 This produces a CALLINFO.BBS door-exit file. Also known
as "WildCat! 2.x" type file.
A Normally we shell-to-dos to run a door program.
However, if this Attribute is ON, we do a full exit.
Taking the entire BBS out of memory and giving it to the
door program to use.
If, when testing a door program, you get "Cannot execute
filename", then this error means that there was not
enough available RAM to run the program. You should
then set this Attribute ON. You should always at least
try a door program without this Attribute--the size of
the .EXE is not a good indicator as to how much memory a
program uses. Most programs will give the quick "cannot
execute" error, but some will work fine, and then get
buggy after using it for a while--so you should set this
Attribute ON for them as well.
See SHROOM.HLP for a swap-to-disk/shrink method you can
also use.
Normally you just set one of 1-7 ON.
Technical note: The software will not read back in the
above door-exit files. However, it always writes out its
own (JDRBBS##.DEF) and will read that back in--adjust the
users record for any changes. See TECHDOCS.DOC and
DOORS.DOC.
Access Security Level (minimum and maximum)
If the user has a Security Level less than the minimum, or
greater than the maximum, specified values here, they will
not be able to run the door program.
-114-
For "DOOR", and "DOOR _g##", these inaccessible areas
simply are not displayed. For "DOOR _#" commands, the door
is not executed.
Menus To call a door program from a menu, you use the "DOOR" menu
command.
This command has 3 formats: DOOR, DOOR _g##, and DOOR _#.
"DOOR" is the easiest to use. It simply brings up an
internal menu of all accessible doors. The user selects a
door program, we execute it, then we return to the original
menu. Doors to which the user has no SL are not listed.
"DOOR _g##" is similar to just "DOOR". But instead of all
doors, we use a pre-created group of doors. See Doors: Group
Handler in the sysop menu for more information. The menu
created is an internally generated one, and doors that the
users does not have the proper SL to access are not listed.
Both of the above are pretty easy, and should be used while
you are getting your doors organized and set up. Once that
is done, many sysops like to design their own door-access
menus.
For that, we have the "DOOR _#" command. Where "#" is the
door entry number (from Door Maintenance) that we should
execute. To use these commands, you first create one or more
menu commands using "DOOR _#". For example:
"dor1" = "DOOR _1"
"dor2" = "DOOR _30"
"dor3" = "DOOR _5"
You then create an ANSI menu with the new commands ("dor1",
"dor2", "dor3") or put one or more of these commands onto an
already existing menu.
Note: the "DOOR" menu command above is NOT the same thing as
the very similar "Door" menu command. "Door" is a quicky
shell-to-dos-and-run-something, and does not create door exit
files nor track time/usage stats.
See DOORMENU.ZIP for information on implementing the pull-
down door-access menus I use on Immortality. These are very
tricky, and you should have mastered the menu system before
thinking about implementing it.
Time Like file transfers, time spent in doors is reduced from the
Maintenance users' daily download minutes available.
A user may call a door as many times as they want. You may
set a "maximum time" a user may spend in a door per session,
-115-
but since a user may use the door any number of times,
ultimately they are limited by their total time available.
Before calling the door, the software will verify that they
have time available.
Technical note: A door program gives minute-credits, or
removes them, for reward or loss, respectively. If a door
program you are installing has the ability to define the rate
of exchange (example: 1 minute-credit = $100,000) then set
this value such that the highest a user would ever attain (in
total) does not exceed 32,000 and the lowest they ever attain
(in total) is not below -32,000. Minute-credits should not
casually be played around with in the doors, they should
represent seriously high goals in the game. A gambling door,
for example, should not use 1:1 minute-credit ratios, but
rather the byte part of the exchange rate ($1,000,000 or
$10,000.00). Currently I know of no program that makes use
of this.
See also: MINUTES
Misc. I have been testing some of the door programs with this
software, see the file DOORS.DOC for helpful information on
setting up various door programs.
To speed up the loading of doors, use PKLite or a similar
utility on the .EXE and .COMs. However, if you get the
message "has overlays, continue?" then answer "No"--these
programs, like JDRBBS.EXE itself, have internal overlays that
cannot be accessed if they are compressed.
When a door is run as an event, no time checking/handling is
done. Since there is no user.
If you set something up wrong, the good door programs will
tell you what was wrong.
Setting up a single DAILY.BAT file which contains all the
door-related events to run at midnight is a lot easier then
setting up different commands for each event. Using "Door"
to call these maintenance programs (or this DAILY.BAT) is
also a lot easier than using "DOOR" for the same thing.
-116-
PROTOCOLS You can change (add/remove/modify) protocols from the
Protocols option on the sysop menus.
Some protocols, such as xmodem, you cannot use to upload--
because they stop and ask you (the sysop/console) for a
filename to use.
For bidirectional protocols, you must use the "BiMd" and
"HSLk" menu commands to get BiModem and HS/Link,
respectively. This is necessary because otherwise the
software will only look for either downloads or uploads--
these commands tell it to look for both. However, their
definitions (command lines, etc.) are still defined like any
other protocol.
Defining When we make references to the "log entry" below, we mean the
log the protocol itself produces to tell us what happened.
Protocols have the following fields:
Defining letter
This is the letter the user sees for "protocol" in their
Profile. If you use two letters that are the same, you
should be sure that their SL ranges do not conflict.
The very first protocol is known as the default protocol,
it is given when the user's selected protocol (somehow) has
no allowable match. You may reassign the default protocol
by using a defining letter of "*".
Access Security Level (minimum and maximum)
The minimum and maximum Security Levels provide a range in
which the user must be to be able to use this protocol. If
they are less than the minimum, or greater than the
maximum, specified then they will not be able to use the
protocol.
For the "Select Protocol" command, it will not display
protocols to which the user does not have SL access.
You can temporarily disable protocols by setting their
minimum value to something very high, like 32000. It is
easier to just disable a protocol then delete it, and
decide later on that you want it back.
Using a min SL and a max SL allows you to direct different
flavors of the same protocol to different users. Example,
in my set up, level 5 users do not get to do Zmodem resume-
later upload aborts, and so I use a DSZ line that does not
save incomplete files for that Security Level.
-117-
Example, DSZ uploading: "pR1" means "delete incomplete
files," and "-r" (eg. "-mrS") means "allow them to complete
their partial uploads. These you should definitely use for
lower-SL users, and allow for higher SL users. Because
lower SL users will cause troubles by uploading duplicate
files--and the protocol will overwrite your old ones
without these extra parameters! But at the same time, one
assumes the smarter higher-SL users know what they're doing
(and that they can lose their higher-SL by doing this file-
replace trick). That they can be trusted that what they
upload is important and should not be hassled by having to
resend the whole thing when it only needs to be completed.
If the Maximum SL value is zero, then it is ignored.
Allowing any SL once the minimum SL requirement is
satisfied.
Success UL letter
This is the letter, when found in the log file, that
declares that the upload was successful.
Fail UL letter(s)
These are the letters, when found in the log file, that
declare the upload a failure.
See Fail DL letter(s) as well.
Success DL letter
This is the letter, when found in the log file, that
declares that the download was successful.
Fail DL letter(s)
These are the letters, when found in the log file, that
declare the download a failure.
Users do not loose any download minutes or download bytes
when a download fails. We then they continue-later the
aborted download then their records are adjusted properly.
However, if you're having trouble with abusive users
downloading 90% of GIFs, then aborting, one trick to
stopping these people is to remove the "E" from the DSZ
protocols for Fail DL Letters, and put it into Success DL
Letter. Thus, aborted downloads will also have credit
reduced. However, this should not be done lightly, as
regular users who really do have a problem with a download
will not like it costing them double-download credits.
-118-
The solution I like to use is to wait until they log off
(or if I notice lots of E's for DSZ transfer lines in the
log) and then simply add those bytes to that users Bytes
Downloaded. Thus, when he next logons, he see's that the
aborting trick did not work.
Technical note: The following is fairly detailed, and you
may not ever need it (recommend you read it only if you are
having troubles detecting bad uploads).
In order for the to correctly identify bad transfers,
either this field must be one character, or the pass/fail
determining word must be one character. Example: DSZ's
pass/fail word is either "E" or "L"--one character. So
you can have up to 3 characters here ("LE"). If some
other protocol has "Bad" for failed transfers and "Good"
for successful transfers, then you must put a "B" or "a"
here, not "Bad", not "Ba", not more than one character
because the pass/fail determining word is more than one
character.
To simplify: the software looks for the "Fail letters"
inside the "pass/fail determining word" and looks for the
"pass/fail determining word" inside the "Fail Letters".
If either of these cases come up true, then the transfer
is determined to have failed.
This allows me to find: "L" or "E"--rather than trying to
find "LE" in the pass/fail word. So, while "LE" will not
be found in "E", "E" will be found in "LE". If you have
"LE" and the protocol leaves multiple letters, such as
"Lbad", then it will not find the "L"--since either "LE"
will not be found in "Lbad" and "Lbad" will not be found
in "LE".
Pass/fail determining word
This is the "word number" of the letter that determines
whether the transfer was successful or not. The word
number of the log entry.
Words are defined as text having a least one space between
them. Example: "A B C" has 3 words, but "A BC" has only
two. If the protocol produces entries that are some times
blank (rather than, say, a zero), then you cannot use it
(unless the trouble occurs after the determining and
pathname words).
Pathname word-number
This is the "word number" of the transferred pathname in
the log file.
-119-
The pathname need not contain a full file path. It should
at least contain the file name transferred.
Percentage of time to give
This is the percentage of upload time (as determined from
2400 baud) that you should give in minute-credits.
No time is taken off for uploading, except with
bidirectional protocols.
This credit is given them in the form of Minute-Credits and
is done at the time the file is validated or whatever other
rules about credit-giving you have. Only minutes are given
(back), not bytes.
Bytes for upload credits is always the same: simply adding
the size of the file to the user's uploaded-bytes total.
The amount this eventually converts into depends solely on
their ratios for their Security Level at the time of
consideration (ie. when downloading).
Description
This is the text the user sees when selecting and using the
protocol.
Log File Pathname
This is the full path and file name of the file in which
the protocol keeps the log of what happens.
Upload Execution
This is the execution line we should use to handle uploads
to the BBS.
In both execution lines, you should include the full
pathname of the protocol driver being used. Example,
"C:\BBS\DSZ.EXE".
The following "%" codes are expanded when found in the
upload/download execution lines:
%P Comm port (1..n) being used.
%L Transfer pathnames file to use (usually FNAMES.CTL).
%B Baud rate (2400, 4800, 9600, 14400, 19200, 38600) of
user.
%N Node (1..n) being used.
%U Path to currently selected File Area.
%F For first filename (of a download session).
-120-
Note: "%P%P%P" expands to "111" but "%P %P %P" is "1 1 1"
(if comm port = 1 of course). That is, no leading or
trailing spaces are added when substituting for these
codes.
Download Execution
This is the execution line we should use to handle
downloads from the BBS.
See Upload Execution above for the "%" codes allowed.
For batch download protocols, you must use protocols that
accept the "@<listfile>" command line order. This
"<listfile>" is FNAMES.CTL which contain a list of
pathnames to send. Typically, the command line will have a
"@%L" to tell it what files to download.
For non-batch download protocols, you must use the "%F".
This takes the first entry in FNAMES.CTL and replaces the
%F with it. Allowing you to send that one filename.
Protocols which can handle the sending of only one filename
are not recommended.
The program is set up to use "DSZ.EXE" for its protocol
driver. To change this to a different protocol driver, such
as GSZ, you have two methods: easy and hard. The easy way is
to just rename it to DSZ (this only works if the command line
parameters follow those of DSZ (which GSZ does), and you do
not need to use DSZ in another protocol). The hard way is to
go into Protocols and change each DSZ entry by hand, and then
go into Executable Lines and change those DSZ.EXE entries.
Renaming GSZ to DSZ.EXE works just fine.
I have not tested the other protocol driver programs (such as
SZMODEM, etc.) for this simple renaming trick, but it
probably will work. Although some, like IceZmodem, have a
non-DSZ compatible command line, and so either need their own
Protocols entry, or for you to modify your current DSZ
command lines.
-121-
MENU SYSTEM Ah, the menu system. The key to JDR_BBS. It's sneaky, may
even appear hard at first. But it is very, very, powerful.
It will be a long time before you master it completely, but
you will be able to master much of it quickly.
This is the KEY! Understand this, and you will understand
the whole software package. Everything makes sense when you
master this, the whole thing becomes a thing of beauty.
Don't fight it, it is really not that tough.
Definition What is a menu?
In the "good ole days" a menu was something the program
itself took care of. The programmer(s) decided how it was to
look and which commands were to be put on it.
More recently, this system has evolved to where we use an
"image" (such as an ANSI) for the menu display. However,
many programs still limited the commands that you could have
on which menus.
Now, we are in an age of much more powerful menu systems.
Where the actual display the user see's is of minor
importance. All the work is done behind the scenes: the
sysop configures for hot-keys to use, Security Levels to
block/allow commands and images, commands that go to sub-
programs, scripts/command builders, and all sorts of
combinations.
This flexibility allows sysops to change software without
having to change too much of the look and feel of their BBS.
In this software, menus are: zero or more images grouped with
zero or more commands. Menu's are referenced by a three
character ID, known as the Menu ID. Typically, a menu will
be a single ANSI with 3 or more commands on it.
There are three parts to a menu: the image to display for it,
the commands to use in it, and the commands themselves.
Please re-read this. Commands are like objects--they do
nothing until put them on menus. In this software, the
"commands to use on a menu" are not equivalent to the
"commands themselves". They can be, and most often are, but
need not necessarily be, because they are built up from other
commands. As you shall see later, the Menu Command system is
separate from the Menu system.
Most everything with this software deals with objects. You
have databases full of object definitions. Commands make use
of these database objects, but are themselves objects. The
menus make use of these command objects. Each step defines
-122-
the direction and power the original object is molded into.
We take data objects and route them, mold them, and shape
them, until they are in a form we deem acceptable for
callers.
The ANSI's and other forms of images (RIP, GIP) you build
outside the BBS software, using something like TheDraw. Once
you know what you are doing, you will find text editors, such
as PC-Write, to be helpful as well to create, edit, and
optimize your ANSI's.
McEditor For this software, creating your menu's involve using the
Menu Command Editor System, or McEditor.
The following files are used by McEditor:
CMDS.DAT --Contains all usable commands.
CATEGORY.DAT --Contains information about which usable
command is in which category.
FX.TXT --Special effects for menu's when a
selection is made.
BBS_CMDS.DAT --Contains commands used in each menu.
MENUS.DAT --Contains each menu.
FX.TXT is the only file you can edit yourself. It contains
the special effects strings that you can display after a
caller selects a command from your menus. It is a standard
text file. See HELP\FX_TXT.DOC for more information.
The remaining files McEditor handles.
CMDS.DAT and CATEGORY.DAT store the functional information
about how each command works. These files are stored in
BBS\GLOBAL\SYSTEM. The bottom half of the McEditor screen is
for editing this information.
BBS_CMDS.DAT and MENUS.DAT store the information for the
menus. The top half of the McEditor screen is for editing
this information. These files are stored in the Style
directory to which the menus apply, for example "1ST".
You can access McEditor in two ways: from the sysop menu, or
just hitting <ctrl>F2 nearly anywhere. Designing menus can
sometimes get tricky--you literally design yourself into a
hole sometimes. For instance, you make a change that stops
your access to the sysop menu. That is why the <ctrl>F2 key
is there.
-123-
The McEditor screen looks something like so:
Menu ID: xxx ANSI: x:\xxxxxx\etc.
┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐
└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘
┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐
└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘
Category: xxxxx
┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐
└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘
┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐┌─┐
└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘└─┘
There is not that much to remember. What you see are
actually two separate systems: the top half of the screen is
the menu system, and the bottom half of the screen is the
command system.
The whole system is an "object oriented drag-and-drop menu
command block-building system".
You can type "?" to get the commands, but they are pretty
straight forward: arrow keys to move, <ins> to create/edit,
<del> to delete, <enter> to pick up and drop down objects,
<pgup> to move to previous category or menu, <pgdn> to move
to next category or menu. <esc> to quit.
"H" will bring up the on-line docs for the menu commands.
You can also use <ctrl>F3 from most anywhere to bring up
these docs.
Use <left> and <right> to move into the Menu ID and Category
fields, <up> and <down> skip past them.
The "?" brings up help (and used hot-keys) when used on a
blank object. When used on a non-blank object, it reports on
the contents of that object. An object being a menu entry,
or a category command (those boxes in the picture above).
To make the commands a bit more readable, "?" will bring up a
"human readable" form of the command as well.
The "/" key can be used to toggle ON/OFF continuous
reporting. When ON, every object you move the cursor across
will have its contents displayed--and the "?" will display
help alone. When OFF, "?" for help only works on blank
objects.
When <ins> is used while at the Menu ID field, or the
Category field, you are able to do a variety of things. It
lets you type something, and then will ask you what you want
-124-
to do. [Enter] alone will abort any operation. Things you
can do include creating new menus/categories, jumping to a
menu/category, duplicating, swapping, etc.
You can move individual command objects around: simply move
over what you want to move, hit [Enter] to pick it up, then
move where you want to drop it, and hit [Enter] again. You
can use this to move commands between categories, to move
menu commands between menus, and to move commands from
categories to menus. It is easier than <ins> which requires
that you type in a cmd4 name.
"@" at the menu commands is useful as well. Just do an "@"
on top of a menu command, and it will locate for you which
category has that commands definition.
You can use "E" to export menus or categories. And "I" to
import menus or categories previously exported (example: a
friend gives you a menu or menu system (Style\Language)).
When importing, it puts the new stuff at the front of what
you currently have (menus or categories). When exporting,
only menus can be saved multiple per file. The type of
import (menu or category) is automatically detected, but to
export, you hit "E" on the menu or category you wish to
export.
It is easiest to just play around with it for awhile.
Just remember that the bottom half defines commands, and the
top half uses those defined commands.
Menus Menus are made up of the following: a Menu ID, a menu ANSI,
and the menu's commands.
Each "page" for the top half of McEditor is for a different
menu. You can create as many of these menus as you want, and
put whatever commands you want on them. The software is in
no way locked down to the menus I have or the ANSI's I use.
These "pages" provide an interface between your commands and
the user: in these "pages" we tell the software what the user
sees (the ANSI), we tell the software what the user can type
(the hot-keys), and we tell the software what its supposed to
do when a key is selected (the commands). But it's still up
to you, the sysop, to draw the ANSI's (with TheDraw or
somesuch) and define the commands.
While I always say ANSI here, you can use .RIP and .GIP
screen images in place of the ANSI image.
The menu ANSI can do all the smart-codes. See ANSI.HLP.
-125-
While the ANSI is being displayed, and after it is displayed,
the software will accept any valid hot-keys for the menu
commands. The hot-keys available depends on the users and
the hot-keys' Min SL and Max SL.
You can quickly turn a menu command ON/OFF by a Y/N for the
active field.
The command itself must be a valid category command, or a
">xxx" jump-to-menu command (which need not first be defined
in the bottom half of McEditor).
The hot-key can be any keyboard character. Including
numbers, and characters like "!@#$%?':,."
The following are special. They work as themselves, but also
tell the software to accept special keys:
hot-key what to accept
~ [Enter]
< <left arrow>
> <right arrow>
^ <up arrow>
_ <down arrow>
If no "~" is defined as a hot-key, [Enter] normally just
redraws the screen (unless pull-down/arrow menus are used,
then it is used to select an option).
Minimum SL and Maximum SL. The user must have the minimum SL
to execute the command. They must also be less than or equal
to the maximum SL to execute the command. If Maximum SL is
zero, then only the minimum SL is used for consideration. By
using upper and lower boundary SL's, we are able to define
multiple commands that use the same hot-key--they could be
designed to work differently for different SL ranges. This
is quite useful, and easier than separate menus.
Special effects is text displayed after the user hits the
hot-key and before the menu command itself is executed. The
special effects themselves (what is shown etc.) is specified
in the file FX.TXT.
You can use "L" to switch between menu systems. For example,
to edit the "WW4" menu system, you would type "L" then the
path to the "WW4" dir: c:\bbs\node001\ww4. McEditor defaults
to whichever menu system you are currently logged in under.
See DOORMENU.ZIP for a complex example about how to implement
pull-down menus. When using pull-down menus, -/+ also works
to move between commands, and [Enter] selects. Even though
-126-
they are called pull-down menus, they can be of any form--
they are just menus that user can move about the screen using
the arrow keys.
See also: ANSI.HLP, STYLES\LANGUAGES
Command First and foremost, all commands are four letters. But they
Objects may have parameters of variable size.
There are three types of commands: "|###", ">xxx", and
everything else.
"|###" are system-level notation--you should never use this,
all functional commands are built upon these notational
(core) commands. These are known as "primitives".
">xxx" is a "jump to menu xxx" where "xxx" is a Menu ID.
This command changes the program flow to another menu. The
first action upon going to a new menu is to display that
menu's ANSI.
Any other 4 letter command is a constructed command. Created
by using the above commands, and parameters for the above
commands.
Parameters for any command always has a leading "_" before
it. Example: "PagF _1", "PagF" is the command, "_1" is the
parameter.
The "|###", ">xxx", and any created 4 letter commands are
referred to as "objects".
When editing a command, there are 78 characters available for
you to define the "functionality" of the command. The
functionality of a command is built up using other commands
and parameters. You can have a remark using the "'"
(apostrophe) character--anything on the line following that
character is ignored.
The key to understanding commands is that each 4 letter
command represents an object, whose functionality is defined
by the commands that make up that object. That is, like
painting, you create new colors from color primitives. Here,
you create new commands from command primitives.
Well, I hope I haven't lost you. It makes a bit more sense
after you play around with McEditor for a while. You will
find that most "regular" commands are a single command. The
ability to build new commands is something for special
situations and to provide further customization. Example,
there is a command to display an ANSI, "dANS". Which is
nice, but the ANSI displays and before the user gets more
-127-
than a glance at it, we're back at the menu. So we look
around a bit, and see the "ENTR" command--which waits for a
user to hit a key. We put them together to have the software
do what we want: display an ANSI and then wait for the user
to hit a key. Which looks just like: "dANS _pathname ENTR"
(quite useful for display top scores files from door games).
Each command/object can be stacked/linked/joined/etc. just
like toy blocks. Think of each 4 letter command (and its
related parameters) as a toy block and the system is easier
to understand.
The key is that this is a block construction language, in
which you take blocks and mix-and-match them.
block types:
┌────┐ ┌─────────┐ ┌───────┐ ┌────┐
│cmds│ │pathnames│ │numbers│ │etc.│
└────┘ └─────────┘ └───────┘ └────┘
you then take these, and form larger commands:
┌──────────────────┐
│┌────┐ ┌─────────┐│
││cmds│ │pathnames││
│└────┘ └─────────┘│
└──────────────────┘
┌────────────────┐
│┌────┐ ┌───────┐│
││cmds│ │numbers││
│└────┘ └───────┘│
└────────────────┘
┌──────────────────┐
│┌────┐┌────┐┌────┐│
││cmds││cmds││cmds││
│└────┘└────┘└────┘│
└──────────────────┘
and bigger:
┌──────────────────────────────────────────────────────┐
│┌──────────────────┐┌──────────────────┐┌────────────┐│
││┌────┐┌────┐┌────┐││┌────┐ ┌─────────┐││┌────┐┌────┐││
│││cmds││cmds││cmds││││cmds│ │pathnames││││cmds││etc.│││
││└────┘└────┘└────┘││└────┘ └─────────┘││└────┘└────┘││
│└──────────────────┘└──────────────────┘└────────────┘│
└──────────────────────────────────────────────────────┘
Thus, you choose the reading difficulty: one big command,
many small commands, or something in between. The software
does not care.
-128-
All the 4 letter commands that exist are "built" upon "|###"
commands. 4 letters is a lot more readable then "|###",
which is why they are there--to make the commands created
more readable. I could have had it use more than 4 letter
commands instead of requiring creating 4 letter commands--but
it actually makes things more complicated. Think of the 4
letter commands as little icons.
I would like to emphasize that while it may sound like a
programming language, it is in fact not. There are no
complex loops, or variables, or any such stuff. Just the
placement of one needed command next to another to produce a
new command.
Commands The easiest way to work with all these commands is to just
take what you need--don't try to create a BBS that uses
everything. Just because there is a phone call-back command,
for example, does not mean a call-back system is something
you would like. There is a wide variety of commands to
appeal to the different needs of different BBS types.
Because of the way the menu system is implemented, you can
change any of these names if you don't like them.
Implicit to all the commands is that they will return to the
current menu when completed.
The most "combinations" a command can have is:
Cmd4
Cmd4 _###
Cmd4 _g##
Cmd4 _all
These break down as such:
"Cmd4" -- work with the current whatever.
"Cmd4 _#" -- work with # whatever.
"Cmd4 _g##" -- show a menu of all whatever's in
group ##, and then do whichever
whatever is selected.
"Cmd4 _all" -- show a menu of all whatever's, and then
do whichever whatever is selected.
That is to say, the commands follow a common "expansion"
system. Where you first work with the current, then a
specified individual, then a selected group, then all. Only
a few commands use all four possible expansions.
Hit "H" in McEditor for a full list of available commands.
Misc. From any menu, the software automatically checks for a Zmodem
or BiModem upload. Users can upload by "just doing it" from
any menu, and the software will detect it and act accordingly
-129-
(jumps into the protocol, no searching done, not done if not
enough space).
When listing hot-keys used in the "?"s help--the dark grey
keys have been toggled inactive.
No matter what we do with menus--loading, moving about,
switching between menu systems, etc. The categories are
always the same, and common to them all. As well as common
to all Styles.
-130-
WAITING FOR The Waiting-For-Caller (WFC) screen contains 6 "objects" of
CALLER SCREEN information: drive space, Callers Log, status indicators, the
bottom line, and (with toggles) memory information and caller
statistics.
There are a bunch of Settings you can change for this "WFC
Desktop". Including the size and colors for the Callers Log
viewport.
We'll begin with the easiest: the bottom line. This line
contains the time and day of week. When a call comes in, it
displays "[RING]" when the phone rings (if using an X00
compatible fossil driver), and displays (quickly) whatever
the modem sends to us.
The drive space section, upper left corner of the screen,
shows the available space on drives you have deemed important
enough to show this.
The callers log, upper right of the screen, shows the last
few callers' log entries. You may scroll this using the
arrow keys.
The lower-left corner has status indicators. In the brown
box is the number of messages waiting for the sysop, and the
number of new files since the sysop's last calls. The Faxes
section isn't working yet.
Below this, first, are 3 modem indicators: "CTS" which is
usually down, "DSR" which is usually up, and "DCD" which is
usually up. When there is an incoming call, first "DSR" goes
down (phone taken off hook) and then "DCD" goes down (carrier
detected). Although, depending how your modem is configured,
"DSR" may do nothing, and is not really needed.
Moving a little to the right we have "Trap". When this is
down, that means we are trapping everything to SESSION.LOG.
Beneath these are two chat indicators. "Chat" is down when
we are trapping chat sessions to the trap file. The two
little faces are down (connected) when the sysop is available
for chat.
Hitting <F8> brings up a daily statistics summary, which you
can scroll through as well (+/-).
There is a debugging Toggle that will show you a little
memory available information.
Here are some more hot-keys from the WFC screen:
F1 brings up a hot-key help screen.
F9 normal console login (with reading of new mail).
-131-
F10 brings up a menu of various stuff to do.
<end> turbo console login (no mail reading).
<alt>d goes to the internal terminal program which you can
use to call other BBSs.
<alt>s shell to DOS.
<alt>z exit to DOS, but take phone off-hook first (callers
will get a busy signal).
<alt>x exit to DOS, leave phone on-hook (callers will get
continuous ringing--normally you do not want this).
F2 toggles on/off whether we should automatically trap
chat sessions.
F3 toggles on/off your available-to-chat status.
F6 toggles on/off screen blanking. When on, the
screen will stay blank until you do another F6.
Note: console beep's are also disabled.
F8 toggles on/off the display of the daily stats.
<pgdn> toggles on/off Trap All
<alt>h hot-list-limitor, see below.
<alt>p port-debugger. This is a command line access to
your modem like all terminal programs offer. It
is useful for such things and verifying that your
modem initialization string works, and looking at
the modems NRAM settings.
<ctrl>Fx will do whatever you define.
Usually it will take a couple of seconds until connection
speed is determined. However, it could last the full "logo"
time-out time if the connection was one you had not specified
in your CONNECT strings database (for instance, this occurs
with 300 baud callers). This is because, for baud rates you
do not want, the system merely waits for that caller to hang
up, or for them to time-out.
Entries are recorded in the Callers Log for these "bad
connects". They are of the form: "Non user called at <time>.
Connect: |...|". The "|...|" is the crucial information. It
will tell you the exact string the software received from
your modem. A bad connection may contain just garbage, a
1200 connection would look like "| 1200<garbage>|" usually
(if you deleted the 1200 entry from the CONNECT strings
database). If you forgot any CONNECT strings, this will tell
you the information you need. Note, however, this line is
also given for connects for net mail and when a user simply
hangs up without entering their name.
Hitting <alt>H accesses the Hot-List-Limitor. This allows
you set a list of user names who are the only ones to be
allowed onto the BBS for a specified period of time. After
that person calls, their name is removed from the list.
After the specified time, or when the list is empty, normal
-132-
callers will again be allowed to log in. To have a name on
the list be able to call more than once, specify their name
in the list more than once.
Hitting F10 brings up a menu with:
Alter Settings --change Settings.
Crash Contact --FREQ/Net FA/Exchange Net Mail now.
File Maintenance --edit file entries.
Post A Message --leave a message in any area.
Remove A File --oust an on-line file.
Toggles --change Toggles.
User Maintenance --edit user entries.
View A File --display a text file.
(exits when RING detected)
The same "Post A Message" command we have at WFC can be used
in a shuttle login menu. This command asks for a FROM: name,
and if that name is that of a current-user, it asks them to
first login. After all, can't have random callers leaving
people messages using other peoples names. However, this
limitation is removed when used from the WFC menu.
There is a Toggle that will let you lock the keyboard from
doing <alt>/etc. commands. When on, all anyone can do at the
console from the WFC screen is <F9> to login locally.
See also: SETTINGS, TOGGLES
-133-
THE "WHO'S ON" Below each menu ANSI, the console will show a user status
STATUS LINE line.
It looks something like this:
User Name--Location 5sl 10calls 2msgs ctn
Which breaks down as:
"User Name" is just that, the callers name.
"Location" is the callers city and state. If flashing,
then this is the text they typed for a chat
request.
"5sl" is the callers show Security Level value ("5").
"10calls" is the number of times the caller has called.
"2msgs" is the number of messages the caller has ever
posted ("2").
"c" appears if chat trap-to-file is on.
"t" appears if trap all to file is on.
"n" appears if sysop-on-next is on.
"PR" appears if the user is undergoing Peer Review.
A music symbol appears when you are allowing users to try
to chat with you.
Users do not see this information line. When you logon at
the console, you will also not see it.
Most communications programs use a locked-down last screen
line or two. Which I am sure worked great in the old days,
and with BBS's that need user command lines, but for this
software it just messed up the presentation too much. Both
because we can use that 25th line for ANSI's, but also
because we use that line for lots of other useful stuff as
well.
-134-
ACCOUNT VALUE Accounts do have value. The harder they are to get, the more
value they have.
Simple higher SL values increase their value.
Adding Peer Review increases the value of all passed
accounts.
Adding other requirements, such as name verification (users
send in proof of their name) or phone verification (call back
testing), further adds value.
Finally, stats are seen by all--so if a user has a lot of UL
credits, that account has worth.
What does this mean? It means you could have troubles as
accounts increase in value. More hacking attempts. Users
selling, or trading accounts. Probably other stuff I have
not thought of.
Another problem, however, is "worthless" accounts having
value. Example: if you give new users free download bytes.
Suddenly its easier for some users to log in as new each time
rather than upload.
You can give old accounts value by setting up "UL credit each
time the file is downloaded" system. Even as part of your
regular system, set it up so that 1% is given again to the
uploader whenever that file is downloaded. This will
encourage users to stick with their old accounts, and to
upload popular files.
-135-
EVENTS All events are done after a user logs off, or after the "WFC
inactivity" time has passed when no user in on-line.
Example: a 00:00:00 event does not occur at 00:00:00. But at
00:00:01 if no user is on. If a user is on it will be
executed after they log off.
There is no forcing a user off for events, or reducing their
time for an event.
If you REALLY need to execute an event at a precise time, you
can create an earlier event (say 15 minutes earlier) to do a
"-Usr" which will stop callers. At this time, however, I am
aware of no events that require they be executed at a
specific--and only that specific--time.
You could also use Security Level-based access start/end
times to limit users out of a time frame. This would be
useful, for example, if you run a real busy BBS and need to
poll for mail each night--but need to poll multiple times
because that BBS also is busy.
Access start/end times are like events. These exist for
Security Levels, and for doors. Unlike normal events,
however, these do have a functional limit: the start and end
time must not cross 00:00:00 (midnight). Examples: 1 am to
11 pm is fine, but 9 pm to 3am will not work. The software
works using a 24 hour clock, so the start/end times you
define must outline a "time bubble" within this 24 hour
clock.
Although I have not confirmed it, I think the events will not
work properly if an event is a full-exit door. I suspect it
will just keep looping running this event. So do not do
full-exit doors for events (if you need to door, use
shelling/shrinking "DOOR"s, or the "Door" command).
To stop the execution of events after restarting the BBS, you
can use the /NOEVENTS command line parameter.
See also: MINUTES
Defining You set up events on the sysop menus.
Events contain the following fields:
Execute it after
This is the time we should do the event. Ideally. In
fact, this time will be used if a user is not on-line. If
a user is on-line, we do the event when they log off.
-136-
But not if after
This provides us with an execution window for the event.
If for some reason we have passed this time, we will not do
the event.
This is useful, for example, to stop net mail polling of a
Hub. You would poll for an hour, then stop.
The command line command /NOEVENTS is useful for stopping
events after your system crashes, but using this time
limitor is a also a good method.
Set this to the same as the event start time to have no
maximum time limit of execution.
Days of the week
Which day or days of the week to execute the command on.
M = Monday R = Thursday N = Sunday
T = Tuesday F = Friday
W = Wednesday S = Saturday
Remember that events that occur after midnight actually
occur on the next day. Example, if you want to have an
event execute in the middle of Sunday night at 3:00am, you
would set the event to execute on Monday--since 3:00am
Sunday night is actually Monday morning.
Menu Command
This is the actual event to do. It is a 4 letter menu
command.
While there are many pre-made events you can do. Most of
the events will need to be created. For example: "NODd
_phone _zone" to poll a net address, or "Door _pathname" to
run a door maintenance utility.
Attributes
1 When ON, we take the phone off-hook before doing the
event, and put it back on-hook when the event is over.
If you have an event that is going to take a few
minutes, you want to do this so callers do not just get
continuous ringing while the event is executing.
2 Disable the event. When ON, the event is inactive and
will not do anything.
-137-
3 Retry every 5 minutes. This is only for the call-out
commands (net mail commands).
If the command did not establish contact with another
BBS, then it is reset and will be tried again in 5
minutes. This only works from the current time to the
top of the hour (example: start it at 2:01am, when it
gets to 2:59am we give up).
If we did establish contact, the event is considered
successful and completed.
Node
This is the node to execute the event on. Usually your
less-used node.
You should not configure two or more nodes to poll the same
Zone at the same time.
Example: you want to poll 1:100/1 and 1:200/1. You can
either set these up as two events on one node, or in two
different "time boxes" on two nodes. But do not, for
example, poll 1:100/1 on node 1 from 1am-3am and poll
1:200/2 on node 2 from 2am-3am. Because in the off chance
of both getting connections at the same time, they would
both use Zone 1's directory (MSGSTUFF\1) and could get
confused.
For different networks (different Zones) there is no
combination that causes trouble. Only when the Zones are
the same, and you are doing it at the same time on multiple
nodes.
Description
A description to help remind you what the event is.
-138-
OH OH! From now on the docs deal with the very complex topics.
Stuff that may confuse you even after running the software
for a few months.
Now is a good time to stop reading docs and play more with
the software.
-139-
STYLES\ These are tricky, watch yourself.
LANGUAGES
Let's begin with some terms.
A "menu system" is a group of menus stored apart in their own
files. They are distinct from other menu systems. The
images (such as menu ANSIs are not really part of the menu
system).
A "Style" is one of these menu systems combined with menu
images. A Style has one menu system, but may have many
Languages.
A "Language" is a group of menu images. Also known as a menu
set, or theme. It can be just a couple menu ANSIs, or more
complex complete-text replacements.
Thus, we have following:
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│Style 1 │ │Style 2 │ │Style 3 │
│ │ │ │ │ │
│┌─────────────┐│ │┌─────────────┐│ │┌─────────────┐│
││Menu System 1││ ││Menu System 2││ ││Menu System 3││
│└─────────────┘│ │└─────────────┘│ │└─────────────┘│
│┌─────────────┐│ │┌─────────────┐│ │┌─────────────┐│
││Language 1-1 ││ ││Language 2-1 ││ ││Language 3-1 ││
││Language 1-2 ││ ││Language 2-2 ││ ││Language 3-2 ││
││ . . . ││ ││ . . . ││ ││ . . . ││
││Language 1-n ││ ││Language 2-n ││ ││Language 3-n ││
│└─────────────┘│ │└─────────────┘│ │└─────────────┘│
│ │ │ │ │ │
└───────────────┘ └───────────────┘ └───────────────┘
I opted not to use "Style X" for the name of Styles. But
instead choose to use 3 character identifiers.
Thus, "Style 1" became "1ST", "Style 2" became "RED", and so
on.
The sample shuttle/matrix logon system can be activated by
just doing:
JDRBBS /1stcmd=SHUT
(to turn it off, do JDRBBS /1stcmd=STRT).
The "SHUT" menu command is stored with the 1ST Style, so for
the above to work, your "Default Style\Language" Setting will
need to be "1ST\1" (the sample shuttle ANSIs are in with the
1\ Language). If you want to do this with the other
Style\Languages as a default, you must duplicate the "sht"
-140-
menu from 1ST into that new Style, and copy the appropriate
files (SHUTTLE.ANS, FX.TXT) into that Style\Language
directory.
Technical note: After a user hangs up, we load the Default
Style\Language. After we know who the user is when the
login, we load their Style\Language. So it is most efficient
if the Style\Language most of your users prefer is the same
one you have configured as the default.
Directories Thus, the files for "Style 1" are stored in 1ST\, and the
files for "Style 2" in RED\, etc. Or more specifically,
d:\BBS\NODE???\1ST\, etc.
Each Style can only have one menu system, and these are
stored in that Style directory (1ST\, RED\, etc.).
Languages are also stored in that directory, but in their own
subdirectories. So "Style 1, Language 1-1" is stored in
"1ST\1\", "Style 1, Language 1-2" in "1ST\2\", and "Style 2,
Language 1" in "RED\1\", etc.
If you look at NODE001\, you will see the Styles\Languages:
1ST\1 \2 \3 \4 \5 \6 \7 \8 \9 \A
RED\1 \2
WW4\1
JDR\1
Four Styles, various numbers of Languages depending on which
Style.
It is a very flexible system. You can add new Styles or
Languages whenever you want. You can easily exchange Styles
(normally) or Languages (less so) with other sysops. Just
ask that sysop for a copy of their Style, plug it in, select
that Style (New Languages user menu) and your system will
both look and feel EXACTLY like the BBS that gave that style
to you.
Above is the easy stuff. To really customize your own
Style\Language you have to learn to master McEditor, and get
a better understanding of how individual files are used and
stored in Languages (the COMMON system).
But first, a little more on directories:
The two important notations are "???" which converts to node,
and "***\&" which converts to Style\Language. Any pathname
may contain these, and they will be converted.
For one node, it really does not matter if you use "???" or
"001".
-141-
But with two nodes?
Well, as it turns out, it only matters if the second node is
to be different from the first.
So, initially, we create our second node by copying all of
NODE001 to a NODE002 directory.
This allows us to completely, and uniquely, customize node 2.
For example, if node 2 is a sysop-only node, you can delete
from the NODE002 directory all the Styles\Languages you
yourself do not actually use.
However, if your node 2 is to be exactly like node 1 (and
these examples apply to nodes 3 to 999 as well), then you
delete most of NODE002 completely.
─┬─NODE001─┬─1ST ─┬─NODE001─┬─1ST
│ ├─RED │ ├─RED
│ └─TEMP to: │ └─TEMP
└─NODE002─┬─1ST └─NODE002───TEMP
├─RED
└─TEMP
When the nodes are two be identical, you should take the time
and go into Alter Pathnames and change all "???" to "001".
This will lock those pathnames to the NODE001 directory. The
only one you should not do this for are the NODE???\TEMP\
entries. Then just keep your NODE002\TEMP directory and
delete all the other directories and files in NODE002.
This trick only saves about 500k (depending on how many
Styles\Languages you have set up), and for the most part is
not worth the extra work. However, if you have more than two
identical nodes, or just don't like trying to keep all the
menu systems in sync, then this may be a good thing.
Alter Pathnames tells the software where the files are, so
you can place them wherever you want.
You can also make files that are not currently node-specific,
into node-specific by using "???" in their pathname (example:
to make the Style\Languages node individual, change the
pathname to d:\BBS\GLOBAL\SYSTEM\LANGS.???). When you do
this, you will have to login into each node separately to
change the files from the sysop menu (example: log in node 1
to change LANGS.001, node 2 to change LANGS.002).
If you have many nodes, and they just have a couple different
styles, what you can do is drop the "???" node identifiers
from the Style and Language files, and pull the Styles
completely out of the NODE??? directories:
-142-
─┬─NODE001─┬─1ST ─┬─NODE001───TEMP
│ ├─RED ├─NODE002───TEMP
│ └─TEMP to: ├─1ST
└─NODE002─┬─1ST ├─RED
├─WW4 └─WW4
└─TEMP
It requires a little trial and error, and a bit of work in
both Alter Pathnames and the menu systems themselves
(changing the location of the ANSIs for example).
Really, this stuff should only be considered by those with 3
or more nodes.
You see, because the Style\Languages contain nothing but text
to read, they do not need to be part of each node directory.
The trick to remember when doing this stuff is to keep the
TEMP directories inside the NODE??? directories.
Heck, you say, why didn't I do this for the release? The
answer is because all those Style\Language directories would
clutter up the \BBS directory. By keeping them inside
NODE001, they are nice and organized.
It doesn't matter where the Style\Language directories are,
just that you have their pathnames right.
There is nothing that says you have to offer the same
Style\Languages on each node. The power of this system
allows each node to produce a BBS look and feel totally
different from each other.
Styles A Style is 3 files and and a Language directory.
Those 3 files are: MENUS.DAT, BBS_CMDS.DAT, and COMMON.LST.
MENUS.DAT and BBS_CMDS.DAT are used by McEditor. They are
the menu system for this Style.
COMMON.LST tells the software which text/image files are to
be gotten from the Language subdirectories, and which from
the BBS\COMMON directory.
The BBS\COMMON directory holds files that are "common" to
more than one Language. That is, files that are identical
between Languages. Rather than wasting drive space storing a
duplicate of each file in a Language directory, we put them
in this COMMON directory. COMMON.LST tells the software
where the files are.
-143-
See BBS\COMMON\COMMON.HLP for more information. Some
pathnames in various menu commands use "_COMMON##"--these are
referencing this COMMON.LST file for the pathname
information.
Languages In the Language subdirectories, you usually find menu image
files (ANSIs), LINES.TXT, TXT_BLKS.TXT, HELPBLKS.TXT, and
some others including .IDX files. Really, any file that that
Language may need could be stored here.
Or, as pointed out above, it is a fairly standard file, it
may instead be stored in the COMMON directory.
If you want to modify a file in the COMMON directory to make
it more unique to a Language; first copy it into the Language
directory, then modify it. Then modify that Style's
COMMON.LST file so it knows to use the copy of the file in
the Language directory.
The COMMON directory can be thought of as a baseline
directory--where the software goes when it can't find the
file in the Language directory. We save space by not putting
it into the Language directory if there is already an exact
copy of it in the COMMON directory.
Your own style What's involved in making your own style? Not much, just
change what's already there. Or creating a new 3 letter
directory, and copying, for example, 1ST\ and 1ST\1 into it.
Merely creating a new directory is not enough, you must
provide a way to change to that directory. That is why the
sysop's menu "Styles\Languages" command exists--to allow you
to define alternate views of your BBS for your users.
Then just edit the ANSIs and text files to your liking. Same
with that Style's menu system. Add more Languages, etc. Get
additional files from the COMMON dir, or maybe just change
those files outright (would affect multiple Languages).
Use the "L" command in McEditor to load and work on menu
systems. Just type "L", then the path to the Style (eg.
"c:\bbs\node001\1st" that you wish to play with.
Each menu system can have menus with Menu ID's that are the
same as in other menu systems. The reason this is OK is
because the ">xxx" goto-menu command does not look outside
the current menu system for its menus.
Menu Commands The "LngS" menu command provides the user a list of all
defined Styles\Languages and allows them to select one.
-144-
When using this command, all Styles need to have a Menu ID
that matches the Menu ID of the menu which has this command.
So that, for example, when we switch to RED\2 from 1ST\1 we
stay at the User Stuff menu. Example: we do "LngS" from Menu
ID 004 in the RED Style, we select the 1ST\1 Style\Language
(only the Style matters), we change to that Style's menu
system, and locate its Menu ID 004 and display that. If that
Style had no Menu ID 004, we would not know where to go.
However, you can put a ">xxx" command immediately after the
"LngS" to tell it which Menu ID to go to (for example: LngS
>001 will switch to the main menu of the newly selected
Style\Language, rather than try to stay at the same Menu ID).
When you switch to a different Style\Language, the software
reloads all its menus and resets all its pathnames to adjust
for any needed pathname changes.
As an aside, there is a User Attribute which allows you, the
sysop, to stop users from being able to change their
Style\Language.
There is also a menu command, "LANG", which can be used to
change a users Style\Language preference. This alternative
allows you to make your own "change Style\Language" menu
rather than having the software generate a menu of all
possible Style\Languages.
Finally, there is THE command. "MENU _path".
I have been very nicely pointing out how a Style contains a
single menu system. But the hard reality is that each Style
is a menu system. And that Languages are not necessary.
Both the Sysop menus and the DOORMENU system are menu
systems. This command switches between menu systems.
When you've mastered McEditor, and bounce around the
Styles\Languages, and understand DOORMENU, and peeked and
were not impressed by the sysop menus, then you are ready to
understand this information. Until then, skip to the next
section.
It is this command that is ultimately executed when you
change Styles. The "LngS" and "LANG" commands hide this fact
from you, but they to are really just aspects of this "MENU"
command.
What the "MENU" command itself allows YOU to do is organize
your menu systems. Unlike the Style\Language-specific
commands above, this command does not change the Node and
Style stuff. It instead merely loads a whole new menu
system.
-145-
These whole new menu systems can be one menu to a thousand
menus. But since its purpose is to organize your menus,
usually its a group of menus that share a common theme.
The sysop menu system is just such an example. I COULD mix
all the "user" menus with the sysop menus--but as anyone who
saw .08 can tell you, that's REALLY confusing.
So I toss them off into their own directory.
There is only one key to remember about actually using menu
systems. That key is that you must change to them before you
can use them, and you must change back when you are done.
Typically, you switch to a menu system with a ">xxx" so it
goes to and displays a menu. That is: "MENU _path >xxx".
Everything that has previously been referred to as "menu
systems" is a lie. The fact is that all the menu systems
together form one giant menu system. When you shift between
"menu systems" you are merely shifting to other branches of
this huge menu system tree.
Styles are "exclusionary" branches. That is, you can only be
on one at a time (for any one node).
But any other menu systems, like the sysop menu system, are
not exclusionary, and are merely "GOSUB'ed" to. We do not
deal with such hassles like node numbers, Styles, or Language
fields. It's a simple "all the files for this menu branch
are in this path, go use them".
Some notes: when the user hangs up in a menu system
everything is reset to normal, and you cannot do a full-exit
door in a menu system (but you can when the menu system is a
Style\Language).
This is the Zen Master command of the menu system for
Juggernaut. When you are able to create groupings of menus
just because you want the organization, and are able to
properly call and return from them, you will have achieved
complete understanding of THE menu system.
In the meantime Grasshopper, study the sysop menu system to
see how it does things. But beware the Black Night known as
DOORMENU, for it is rumored to be even more complex.
-146-
TEXT FILE The Text File Management System allows the sysop a method to
MANAGEMENT organize text files. It is both a G-Files and Bulletins
SYSTEM system.
It is quite flexible, and based on the "TXTF" menu command.
"TXTF _#", where "#" is 1 to 999.
It stores the text files in an archive (TXTF_###.ZIP). For
example, "TXTF _1" uses "TXTF_001.ZIP".
It uses an access interface exactly like <alt>d.
See also: TXTF, TERMINAL PROGRAM
-147-
DIRECTRY'S Directry's are collections of information stuck into one
file. Also, notice it's spelled "Directry" not "Directory".
There are three files for each directry: DIRECTRY.D##,
DIRECTRY.T##, and DIRECTRY.I## (which the software creates
and maintains).
DIRECTRY.D## contains the information (the Data). This file
has the format:
HEADER/NOHEADER
%%%
text line 1
. . .
text line n
%%%
text line 1
etc.
The first line contains whether the screen should be cleared
and the logo (LINES.TXT line 001) displayed
(HEADER/NOHEADER). The second line is our first "separator
line" and consists of "%%%". From then on we alternate
between information and "%%%" lines.
DIRECTRY.T## files contain the Titles, and are of the form:
First line: Line of text that makes up the heading.
2nd line : Text of the question to ask.
n lines : n lines of titles for each information element
in the DIRECTRY.D## file.
The size of the longest title determines how many titles
are put on each line for the selection menu. Using a max
title width of 20 will get you 3 entries per line.
## corresponds to a value of 01 to 99. Directry files need
not be in sequential order: 5, 19, 37, 88 or 1, 2, 3, 4 are
OK.
See the menu command "DirV" for information on setting it up
in a menu.
When called, the list of titles will be displayed, a
selection made, and the information corresponding to that
selection/title will be shown.
The whole system is designed for you to create whatever
DIRECTRY's you want--up to 99 of them. I have included
three samples: Unprotects, ANSI's, and Music Quotes.
-148-
Use HEADER if you want the BBS logo header line to be
displayed above each data item. Use NOHEADER if you do not
want anything displayed above the data item (usually implies
the data item will handle it). Anything else besides HEADER
or NOHEADER will be displayed above the data item.
You can use LINES.TXT codes in the data text.
Just use a text editor to create/modify the .T## and .D##
files, then just restart the BBS--the .I## files are
built/updated automatically.
It is a very nice and powerful system once you realize how
simple it is. But it is not quite as automatic/efficient as
the Text File Management System. But it can handle
everything from single line quotes to full screen ANSIs.
See also: DirV, LINES.TXT
-149-
USER VOTING This software supports two types of user voting: a message-
based Peer Review system, and an InfoForm-based sysop review
system.
Peer Review Peer Review is a restriction system--to restrict users.
To turn it ON for all new users, set Attribute "0" to ON for
#NEWUSER (you will need to do this again if you ever re-
initialize #NEWUSER). To turn it ON for a single user, set
"0" to ON in that user's record with "User Maintenance".
When reading mail, when you, the sysop, hit "*", the message
is sent to a review file, and the user is tagged as
undergoing Peer Review. Should you hit "*" for another
message from a user undergoing Peer Review, then this message
is also added to their review file.
When users of a defined Security Level value range log on,
they may vote on these review files. To lessen the hassle to
those users in the range, they are only given one to do per
logon. Those already voted on are skipped, and users may not
change their vote. If the user hang's up while in the voting
mode, their vote is cast as "Don't Care" for that review.
At each logon, a user undergoing Peer Review will be given
the tally so far and offered a chance to see what the voters
see.
When the number of positive or negative votes exceeds a value
you specify, then that user is said to have passed or failed
Peer Review. They will be given whatever SL value you
specified. A message will also be sent to them telling them
they passed or failed.
When a user passes or fails, that fact is recorded in the log
for all to see--so those who care about how the voting went
can find out. The complete review file is moved into
DEL_MSGS.TXT.
This system can be useful for limiting beginner users. It is
also useful for accounting. If you double-bytes-off a user,
and they go below their ability to download, this process
discourages "jumping to another account" and encourages one
to repair their account rather than abandon it.
When a user is undergoing Peer Review: during the login
process, if they do not have any mail waiting, they are
offered a chance to see what the voters see.
See also: SETTINGS
-150-
Sysop Unfortunately, this software does not yet support the popular
InfoForms "User fills out InfoForms, other users vote looking at those
filled out InfoForms". Maybe next version.
What it does have is something similar: user fills out
InfoForms, and sysop decides whether to let user have higher
access.
It works pretty simply: you have new users (or those applying
for higher access) fill out one or more Questionaires. Then
you use the view questionaire command to look through them,
deleting them, etc.
When a user fills it out to your desires, you later give him
higher SL manually.
This system is not as troublesome as it sounds. And you get
the most important part right: the user fills out InfoForms.
It's just the "voting" system which is different from normal
(and this is invisible to the user anyways).
The InfoForm method is nice because you get to use some
rather nice looking ANSI questionaires. However, the Peer
Review system lets you get more in-depth detail about a user,
as well as a long sample of their writing (the message(s))
which is a very good indicator of maturity.
See also: MENU COMMANDS
-151-
DATABASER The DataBaser system is a sysop-designed data base system.
All DataBaser databases rely on DB_BLKS.TXT to define a
database, and the "DBEd" or "DBVw" menu commands to access
the database. This makes the whole system (mostly) free from
any hardwired code.
If you decide to take the time to understand this system, you
will be able to create custom databases which users can
access, as well as being able to create database definitions
which can be used to access data files from other programs.
Just one thing to remember: do not modify the stuctures of
any databases I have pre-created. They all have very
specific coding inside the software to use certain data
structures.
When you List the contents of a database, you can start the
listing from any record by merely typing in the record number
instead of the "L" for List at the command line.
Many of the ready-made databases also offer up "!" which let
you access records using a scrollable window.
DB_BLKS.TXT Each DataBaser definition has a format along the following
DataBaser lines:
Structure Line 1: Descriptive text about the database. Appears
... when the "DBEd" menu command is called.
Line n: <end>
Line n+1: database's file name.
Line n+2: database's definition specs.
Line n+3: Question line to use when modifying.
Line n+4: The object name of the record type (subject of
the database).
Line n+5: Heading output text. Appears at top of listing.
...
Line n: <end>
Line n+1: Body output specs.
...
Line n: <end>
Line n+1: Field to use for the windowed selector.
Line n+2 to end: text describing each field.
Example:
50
Fuzzy Bear's data base of warez.
50
50<end>
50C:\BBS\GLOBAL\SYSTEM\FUZZY.DAT
50S12S40U
50record number :
50warez
50 -------- Fuzzy'z Warez Data Baze -------->
-152-
50 Rec ==File Name== ===============Description============== ========User=======>>
50<end>
50
<04
<13 <40 <19~
50<end>
502
50File name
50Description
50User name
The "50" means this is block number 50 in DB_BLKS.TXT (and it
comes only after block 49 and before block 51).
50
Fuzzy Bear's data base of warez.
50
50<end>
Is our description text. It can be any number of lines, but
must be at least two lines, and the last line must contain
only "<end>". It may contain LINES.TXT codes. A CR/LF is
assumed after each line.
When this database is called, it will clear the screen, print
the BBS heading, print "Fuzzy Bear's data base of warez." in
dark green letters, skip a line, then ask the "List, Add,
Modify, Delete, Insert, or [Enter] to quit" question.
50C:\BBS\GLOBAL\SYSTEM\FUZZY.DAT
This is the file name in which we store our database. You
can specify any pathname you want.
50S12S40U
This is the database's definition specs. The following are
currently allowed:
A for an attribute field. Inputs and displays attributes
using "1234567890ABCDEF".
D for a date field (dd-mmm-yy). Odd is that you will see
dd-mmm-yy, but when entering the data you must use the
old mm/dd/yy format.
F for file areas. Input is for a 3 digit number, but
output contains the number and the title of the area.
I for an integer number (-32767 to 32767).
L for a long number (-2,100,000,000 to 2,100,000,000).
M for message areas. Input is for a 3 digit number, but
output contains the number and the title of the area.
N for a net address (xxxxx:xxxxx/xxxxx).
S## for a string of length ##. ## must be two digits.
Example: for a string of length 4, use S04.
S64 is special: it is considered to be a pathname, and
-153-
will be created if it does not exist and the entry you
make ends in a "\".
T for a time field (HH:MM:SS).
U for a users name. The auto-name-detect is in effect
so only active BBS users names are allowed. Use S30
for non-auto-name-detect name fields.
W for the seven days of the week (MTWRFSN). "R" for
thursday and "N" for sunday.
anything else will cause trouble.
Our example describes a database of 3 fields: a size 12
string field, a size 40 string field, and a user name field.
For a total record length of 82 characters (user names are
limited to 30 characters).
For those who need to know: A, D, F, I, M, T, and W are
stored in 2 byte integer form, L and P are 4 byte long form,
U is a 30 byte string, N is a 6 byte string, and S## is a
string of length ##.
50record number :
This is the "modify which entry" question fragment. For
adding, deleting, inserting, etc. it asks "Modify which ..."
and appends the above.
50warez
This describes what we are working with. It is used when
listing. As in "List of all warez."
50 -------- Fuzzy'z Warez Data Baze -------->
50 Rec ==File Name== ===============Description============== ========User=======>>
50<end>
Is our header text. It can be any number of lines, but must
be at least two lines, and the last line must contain only
"<end>". It may contain LINES.TXT codes. No CR/LF's are
added unless you put them in with ">".
50
<04
<13 <40 <19~
50<end>
This is our output display definition line. It contains two
defining elements: "<##" which is the length to use, and
everything in between. For each definition in our definition
specs, there should be a corresponding "<##". You cannot
not-do a field, but can not-show a field by using "<00". The
first one is for the record number. Two numeric digits are
required (for example, not "<9", but rather "<09").
-154-
The example tells the software to display a line of the
database as so: Turn bright green on, display the record
number in a area 4 characters wide, display a blank space,
turn bright blue on, display the filename in a area 13
characters wide, display a space, display the description in
an areas 40 characters wide, display a space, display the
user's name in an area 19 characters wide.
We could have used two spaces before <13 and used <12
instead, or no spaces before and <14 instead--since the field
is only 12 characters in length, the first two will always be
spaces.
The <19 truncates our 30 length file name. Output lines
cannot exceed 79 characters (the software chops off anything
longer).
A "~" will be replaced by a CR/LF.
All lines before the <end> are merged together before
handling is done--so instead of thinking of it as a bunch of
separate lines, think of it as one line broken up.
When displaying, the following formats are used:
Time: fixed "00:00 xm" format.
User name, String: left justified.
Integer, Long numbers: right justified.
Days of week: MTWRFSN with "off" days getting a space.
Attributes: 1234567890ABCDEF with OFF bits getting a space.
File/Message areas: "### title" with title left justified,
use <## to limit what you want to see.
Node address: "xxxxx:xxxxx/xxxxx" format.
502
When accessing this database, we may use "!" to select by
field. This line tells the software to use the 2nd field
(Description). This line can only specify a S## (string)
field. If you have no string fields, you should put a 0
here.
50File name
50Description
50User name
These are the field names used when entering/modifying a
record. Simple names, one for each definition spec. You may
include ANSI codes to colorize them.
When entering a day of the week, or attributes, they can be
in any order, MRF need not be entered as "M R F ", for
example.
-155-
Because it is easiest to start a new database by merely first
copying the definition of another database, the most likely
problem that occurs is that one forgets to change the blocks'
numbers to give it a unique block number.
The limits: 32,767 records with maximum record/field size of
4096 bytes. Maximum of 24 fields (any more screws up the
screen editing).
I know the above sounds rather technical, but there are 50+
that you use already as part of the sysop menus that you can
use as examples.
Calling Via Calling up a database involves using a "DBEd" or "DBVw" menu
Menus commands.
Any user with access will be able to do all the functions
(List, Add, Modify, Delete, Insert, etc.) with "DBEd".
Users are only able to List the contents of a database using
the "DBVw" menu command.
See also: DBEd, DBVw
Modifying When modifying the data, just hit [Enter] at the start of the
line to not change what is already there.
The software will jump through hoops to try to keep groups,
Messages, Files, etc. in proper order as you Delete/Add/etc.
new areas. However, commands that make a specific reference
to an area are not adjusted, and you may need to do it by
hand later. Example: if using a "DOOR _15" command on a
menu, and then you delete door entry number 10--so what used
to be door entry 15 got shifted to number 14.
More When listing, lines that are just "S##" commands that are
themselves empty, are not displayed. For example, a Title
line, which is an S50, is not displayed if it is blank. The
purpose of this is reduce screen clutter of unnecessary
information.
EXAMPLE
┌───────────────────────────────────────────────────────────┐
│ Let us create a "news items" database. In which users │
│ can add/delete/modify/list entries of news items they │
│ think other users would be interested in. │
│ │
│ Step 1 │
│ Find a location for our DataBaser definition block in │
│ DB_BLKS.TXT. Usually just use the next one following │
│ the last block in the file, for example, we will use │
│ 43. │
-156-
│ │
│ Step 2 │
│ Create some informational text for whenever this │
│ database is used. │
│ │
│ 43
Important news items you wish all to see. │
│ 43 │
│ 43<end> │
│ │
│ This displays "Important news..." in dark green │
│ coloring followed by a single blank line. │
│ │
│ Step 3 │
│ Assign a file name to store our data. │
│ │
│ 43C:\BBS\GLOBAL\SYSTEM\NEWS.DAT │
│ │
│ Step 4 │
│ Define the data structure to use. We want a more "free │
│ flowing" structure than normal. │
│ │
│ 43S72S72S72S72 │
│ │
│ Which is 4 lines of length 72 (4 string fields of │
│ length 72). We could add more (or less) of these, we │
│ could change their size, etc. But this provides a good │
│ balance between drive space and entry size (each entry │
│ will use 4 * 72 bytes of drive space). Also, it is a │
│ good size to fool the user into thinking they are not │
│ entering into a database--as it will look like a text │
│ file (when we are done). │
│ │
│ Step 5 │
│ Now we enter the text for the question when a user │
│ selects to modify a record. │
│ │
│ 43news item (1..n top down)?
│
│ │
│ Step 6 │
│ Identifying the record. "What it is" we are adding, │
│ etc. This is meant to be a singular noun. │
│ │
│ 43news item │
│ │
│ Step 7 │
│ Create a heading. │
│ │
│ 4326
News items of │
│ 43 interest.>> │
│ 43<end> │
│ │
│ We output "News items of interest.<ret><ret>" in bright │
│ green for our heading. │
-157-
│ │
│ Step 8 │
│ Design the record display line. Here is where we take │
│ advantage of some of the DataBaser system's qualities. │
│ │
│ 43<00 <72~ <72~ <72~ <72~ │
│ 43<end> │
│ │
│ We use " <72~" to print out each of the record lines │
│ with 4 spaces in front and a CR/LF afterwards. If the │
│ line/field is blank, then DataBaser will not output it, │
│ because it does not output lines with only one field, │
│ and with that field blank. The "<00" says to not │
│ output the record number (actually, it says "output the │
│ record number into a field of size 0). The last "~" │
│ will result in an extra CR/LF between the outputted │
│ records. │
│ │
│ So, now when we list, it will list all entries, │
│ separated by a blank line. It will only list as many │
│ lines per entry as contain data. Example: an entry │
│ with 2 lines of text shows only 2 lines, etc. Not a │
│ steady 4 lines per output record, even though the │
│ record can work with up 4 lines--by stopping output of │
│ "blank" lines, the actual number of displayed lines │
│ will vary with the number of fields witch actually │
│ contain data. │
│ │
│ 43
}7<02
<72~ <72~ <72~ <72~ │
│ 43<end> │
│ │
│ Could be used to display the item number as well. │
│ Above the items appear in the default dark white color, │
│ here we turn on dark blue for the number, and dark │
│ white back on for the text. │
│ │
│ Remember, this entry does not define how each line of a │
│ record is to be displayed, but rather how the whole │
│ record is to be displayed. │
│ │
│ 43<00|o| <72|o|~|o| <72|o|~|o| <72|o|~|o| <72|o| │
│ 43 <*-+-*> │
│ 43 |o| │
│ 43<end> │
│ │
│ This is another example. This displays each item in a │
│ "paper feeder" like format. With a short design as a │
│ separator. Remember that the lines are all linked │
│ together to form a single string. │
│ │
│ Step 9 │
│ We have no fields which could be used to select records │
│ with the windowed selector, so we just use: │
-158-
│ │
│ 430 │
│ │
│ Step 10 │
│ Because we have defined four fields (S72 * 4) we must │
│ now give each a name (for when we add/modify the │
│ entry). │
│ │
│ 43Item │
│ 43Item │
│ 43Item │
│ 43Item │
│ │
│ When adding/modifying an entry, we will be adding to 4 │
│ fields with the same name. But because the whole │
│ record is considered a single news item, this is quite │
│ appropriate. │
│ │
│ Finally │
│ We have completed a new database. Now we just give it │
│ an entry on a menu's ANSI, and a matching entry in │
│ McEditor with the command "DBEd _B43". Review the menu │
│ system for help with this procedure. │
│ │
│ NOTE │
│ While this database was designed to let users add │
│ entries, you can utilize it as your primary news file │
│ as well. Either replace the "Dnws" with a "DBVw" or │
│ add a "DBVw" command before or after "Dnws". Then when │
│ users log on, they will get a listing of your news │
│ DataBaser contents. │
│ │
│ One drawback with this database--any user can modify │
│ any other user's news item. Well, it might actually be │
│ useful here, but it would be disastrous if this were, │
│ say, a Buy/Sell/Swap database. │
└───────────────────────────────────────────────────────────┘
-159-
LIFE & DEATH There are many aspects to this capability, as it has many
DELETE requirements and conditions that must be met to both
implement it and for a user to use it.
This section only covers L&D Delete, the Life & Death system
is better explained in the Toggles and Menu Commands which
implement it.
To implement it:
Set the toggle to allow it to ON.
In "Change Settings", set a minimum amount of drive space
before this becomes active, and set a minimum user SL value
who may use it.
In your menus, have an entry for "Asst" (usually in your
login loop). Use an "ifSL" entry to give it the same SL
value as we do in "Change Settings".
You may also need to specify a file contents listing form
type directive to display the L&D value for each file.
To remove it:
Set the toggle to allow it to OFF.
Remove the "Asst" menu entry.
Every thing is individual. "Asst" will display the AI help
request to anybody, which is why we set the SL field in the
menu command itself. When using the L&D system, any user may
attempt to delete it--which is why there is a Change Settings
SL value. That user could do it at any time, which is why
there is a "only if less than this amount of drive space"
Change Settings field.
It is complex because it needs to be. This capability allows
users to delete files from your download directories. So you
must be able to define who can delete, and when they can do
it.
Users will not be able to use L&D Delete to delete files in
"CD" File Areas (those with Attribute 9 ON).
-160-
MULTI-NODE This software has complete multi-node capabilities.
OPERATIONS
To use it under multiple nodes, you will need a multi-tasker
like DesqView, Windows, OS/2, etc.
SHARE.EXE will need to be installed for multi-node operations
under MS-DOS and DesqView (not sure about Windows, or OS/2).
See the HELP directory for sample DV and Windows .PIF files.
One thing that should really be useful is a "sysop node"--you
set up a node that nobody can contact via the phone, and just
switch to that multi-task window when you want to logon.
This allows you to avoid waiting to access your own BBS.
Steps to making a Node 2:
1) copy the whole NODE001\ tree into a NODE002\. If the
second node is just for you, you don't have to copy over
any Styles\Languages you don't use. The main thing we
want is that NODE002\TEMP\ directory.
2) copy BBS001.BAT to BBS002.BAT. Then edit it so it
contains /NODE=2 rather than /NODE=1.
3) now restart node 1 as normal (BBS001.BAT). Then go into
"Change Settings", and change the Node number from 1 to
2. This will create a SETTINGS.002 file.
4) Log out of node 1 as normal. Then with your multi-
tasker switch to/create a task for node 2. Then run
BBS002.BAT from that task.
Thus, you now have two nodes. BBS001 starts node 1, BBS002
starts node 2.
If your node 2 is a sysop-only node, you'll want to change
its comm port right away to 0 (local-only operations).
Although if you have two modems installed, you can also just
use that comm port (maybe for calling out, etc.).
If you use the sample .PIF's you will probably be OK. But
feel free to play around. It is important that you have a
good idea of how to use your multi-tasker before trying this.
More than one node is more work. You need to implement
multi-node modes for many door games, for example.
The main thing to remember about multi-node operations is
that when you change things for one node, to remember to do
it for the other nodes as well. Such things include menu
commands, text, and ANSI files.
Multi-line BBS's have a few pitfalls that it is the
responsibility of the sysop to avoid:
-161-
One pitfall is lack of drive space--always make sure your
basic empty space is enough for all the nodes (about 1 meg
per node should be available free on disk at all times).
With events: that you specify a node for each.
With net mail: that you don't have multiple nodes
sending/receiving for the same zone at the same time.
Important: The Settings and Toggles are node-independent, you
can change these for each node. Example: you could toggle on
"must validate uploads" for node 1, and toggle it off for
node 2. Pathnames, however, are not (which is why we have
the "???" and "***" specifiers).
Never shell to DOS and modify the various BBS-use block text
files (TXT_BLKS/DB_BLKS/etc.). You must do a full exit, then
edit them, and then restart the BBS (all nodes). The reason
is simple: the software maintains an index of where each of
these blocks start in the text file--adding or removing
characters screws up this index, and could really mess things
up.
When you restart the BBS, restart it in an orderly fashion:
wait till node 1 is up and going (at or past WFC) before
going on to node 2, etc.
There are some things that when you change you should restart
all nodes so they learn about the changes:
When you change LINES.TXT, TXT_BLKS.TXT, SYS_BLKS.TXT,
PRG_BLKS.TXT, DB_BLKS.TXT, SHORT.TXT.
When you add/delete Security Levels, Message Areas, File
Areas. If you do something minor, like change the number
of access minutes for an SL, then there is no reason to go
through the hassle of restarting the BBS--the other nodes
will get that minor change eventually.
When you change pathnames in Alter Pathnames.
You may want to make the Trap All and Trap Chat files node
dependent. It depends on how much you use trapping.
See also: FILE AREAS, LANGUAGES/STYLES
-162-
INTERNAL NETS These are networks between two or more computers. Such as
linking up all the computers in your home.
For all of the above, you should not specify a "0" for comm
port. They must point to valid comm ports to work properly.
Null Link This involves connecting computers via a null modem and using
JDR_BBS as a medium on one or more of your computers.
You must specify in your fossil driver line each port. For
instance, I have an old HST connected to COM1 and a null
modem connected to COM2, and use the following CONFIG.SYS
line:
driver = x00.sys b,0,19200 b,1,19200 r=4096 t=2048 e 2
Which locks the baud rate of the old HST (b,0,19200) on COM1
and the null port (b,1,19200) on COM2.
There are two ways to connect up two computers via a null
modem using JDR_BBS.
The first method is for when both computers are running
JDR_BBS. This involves going to the waiting-for-caller
screen of both computers, and selection <alt>p and changing
two whatever comm port the null modems are connected to.
This is a hard link, from which you can use <alt>s, <pgup>,
or <pgdn> only.
The second method involves JDR_BBS being on one computer run
as a straight BBS, and JDR_BBS on the other computer in
<alt>d. For both computers, you will need to first use
"Change Settings" to set the comm port to your null modem--
you will need to repeat this step when you are done. This
allows you to use all the <alt>d commands.
You can mix and match the above, <alt>p, <alt>d, Settings, it
does not really matter. What matters is that you get both
computers pointing to your null modem.
It might be more convenient to set up multi-tasked "sysop
nodes" on each computer already pre-configured as a null
modem connection. Giving it no timer ticks until you need
it.
LANs LANs are computers networked together using something like a
LAN card.
LANs hooked up as a way of storing your on-line files, or
with each computer handling a node is no problem at all.
-163-
But if you want the networked computer to act like a dumb
terminal to the BBS, then you need to configure the LAN card
like a comm port. That is, the software will send and
receive data only to comm ports.. So if you can configure
your LAN card to work via a fossil like X00, it will have no
trouble acting like a sysop-only type node. There is a
Miscellaneous Toggle related to this. When this toggle is
ON, the BBS will not try to reset the modem for that node,
and will simply wait at the login screen until a user logs
in.
Null LAN For lack of a better term.
Interlink was real easy to set up. First, on your main
system, (the one with the BBS on it) all you have to do is
add "Device=c:\dos\interlink" to your config.sys. On the
second machine, just type "intersvr" at the dos prompt.
Thats all there is to it. When the first machine (the main
one) is booted up again, it searches the second one and
adds all the drives on that machine to the main one. That
is, you can now access the second machine's drives from the
first one. In the BBS, all you do is change the individual
file areas to point to a drive on the other system to use
it as a file server. If I got you confused here, I'm sorry.
It's really quite easy. The only added expense is buying
the interlink cable. It cost me 8.99 at radio shack. It was
made just for interlink. The only drawbacks are that the
second machine is now only a file server. You can't use the
system cause when you take it out of interserver mode, it
breaks the connection. Also, getting a printer to work
might be a little tricky. I had to tell my printer software
to use "lpt2_dos" as a port to get it to work. Other than
that it really is a lifesaver of a program. It frees my
main system's hard drive up to do more with. I use the
other system strictly as a second hard drive for the board.
--Roland Parent
It frees a possible Stacker drive (which normally would be
very inefficient with File Areas), and allows one to get
around the 2 drive IDE limit. The cable Roland mentions I
think is just a null modem and connecting cable.
-164-
FILE With all the I/O being done, it is inevitable that you are
CORRUPTION going to get some sort of file corruption.
Executing a: CHKDSK /F will fix these problems.
However, CHKDSK may fix it by increasing a files size
(particularly for allocation errors). For text files this is
not a problem. For the USERS.HDR, FILELIST.HDR, and
MESSAGES.HDR, you should run the appropriate integrity
testing command. For other .DAT files, you can use their
DataBaser menu commands to edit them to find any visible
problems.
If you have Trap All ON, and shell to DOS and delete the
SESSION.LOG file, you most likely will get a fatal "sector
not found on drive d:" and have to reboot the system. This
occurs because I do not close my files when shelling to DOS.
The reason I do not close them is because <alt>s could be hit
anywhere, and I have no way of knowing which files are open.
DOS does not like you deleting its opened files.
If any of the .IDX index files become corrupt, just delete
them and restart the BBS, they will then be recreated (you
should restart all nodes). You can tell the users index, for
example, is corrupt if you are not allowed to enter what you
know to be a valid user's name, or if the data returned about
an account is wrong, or that of another user. You can tell
the files index is corrupt, for example, if after entering
two characters of a filename to download the system crashes.
Generally, if something is acting bad with messages or files,
its usually that a .IDX file got messed up.
File corruption doesn't occur a lot. But computers today are
increasingly hostile places for files. Virus's, for example,
have ballooned into a real threat. You should make some
effort to back up your BBS regularly. By far, the reasons
most BBS's go down is a) because the sysop got tired of it,
and b) because the HD crashed.
-165-
SPECIAL THANKS To the users of Immortality--who have been putting up with
oft-times flaky software and a non-attentive sysop for three
years now as I have developed this software.
Ray Elquist. Who, despite being long distance, was largely
responsible for beta testing .09. His many found bugs and
ideas have caused the long delay between the .08 and .09
releases, but the program is much better because of his help.
Bob Ratliff. Who seems to be spending so much time testing
BBS programs that I wonder why he registered. His
dissatisfaction has made the .10 version easier to use.
-166-
NEXT There are docs, doc files, and help files hiding everywhere.
If you really want to read more docs, then seek those out.
But no hurry, play with the software some more--it gets
better the more you use it.